Skip to Content
Technical Articles

Dealing with default file permissions (umask) on NW AS ABAP on Linux

 

Recently i had to deal with default file permissions for files created by NW AS ABAP. In Unix the permissions a file is created with are typically controlled by the so called umask. If a process is creating files it uses typically the umask set for the user which started the process.

The SAP NetWeaver Security Guide talks in the Linux/Unix section a little bit about umask but doesn’t recommend any specific value. Besides setting the umask on user level there are also several parameters in NW AS ABAP which deal with umask for different files created during startup and runtime.

Since these parameters aren’t very well documented [1] i had to analyze their impact in detail.

As a disclaimer, in real life scenarios there may other files be affected additionally to the ones mentioned here, for example files created with ABAP routines (e.g., files in the transport directory), SPOOL stored on the filesystem or job logs. These are not covered in my testings.

 

Analyze the impact of umask

 

Therefor i set up openSUSE Leap 15.1 with NW AS ABAP 7.52 SP 04 Developer Edition on Sybase on top in my virtualbox as my test system.

Since NW AS ABAP Developer edition comes with an easy installer where just a running system gets extracted, i had to cleanup some directories:

stopsap ALL
stopsap sapstartsrv
rm /usr/sap/$SAPSYSTEMNAME/*/data/*
rm /usr/sap/$SAPSYSTEMNAME/*/igs/log/*
rm /usr/sap/$SAPSYSTEMNAME/*/log/*
rm /usr/sap/$SAPSYSTEMNAME/*/log/sap*/*
rm /usr/sap/$SAPSYSTEMNAME/*/work/*
rm /usr/sap/tmp/*

 

Which umask might be suitable?

 

  • umask = 007 (removes all permissions for others)
  • umask = 027 (as above and additionally remove write permissions for group)
  • umask = 077 (removes all permissions for group and others)

For my testing i decided to use umask = 077.

So lets start gather some data

  1. Perform the cleanup as listed above.
  2. Set one of the relevant parameters to 077 and start the system.
  3. Logon with SAPgui, perform some actions.
  4. Stop the system.
  5. Export a listing of all files and folders in /usr/sap/$SAPSYSTEMNAME/.
  6. cleanup.
  7. repeat.

 

stat/umask

 

Default value: 022

With this parameter set to 077 the following files are created with adjusted permissions:

-rw-------   /usr/sap/NPL/D00/data/stat*

So this parameter affects indeed only the statistic files. One should consider to adjust the parameter since statistic files may contain sensible data.

 

service/umask

 

Default value: empty

Fun fact: the Developer Edition seems to be packaged with stricter settings than applied when running. So some of the files mentioned below are packaged with -rw-r—– but after the first restart and logrotation they geht er-created with -rw-r–r–.

With this parameter set to 077 the following files are created with adjusted permissions:

-rw------- /usr/sap/NPL/D00/log/ALMTTREE
-rw------- /usr/sap/NPL/D00/log/ALAGENTALERTS
-rw------- /usr/sap/NPL/D00/log/ALPERFHI
-rw------- /usr/sap/NPL/D00/log/ALALERTS
-rw------- /usr/sap/NPL/D00/log/sapccm4x/agent.lock
-rw------- /usr/sap/NPL/D00/log/sapccm4x/oscolfilter.ini
-rw------- /usr/sap/NPL/D00/log/sapccm4x/sapccmsr.ini
-rw------- /usr/sap/NPL/D00/log/sapccm4x/sapstartsrv_ccms.log
-rw------- /usr/sap/NPL/D00/log/sapccm4x/logsave.bin
-rw------- /usr/sap/NPL/ASCS0/work/INSTSTAT
-rw------- /usr/sap/NPL/ASCS0/work/stdout*
-rw------- /usr/sap/NPL/ASCS0/work/available.log
-rw------- /usr/sap/NPL/ASCS0/work/NPL_msg_server_adtl_storage
-rw------- /usr/sap/NPL/ASCS0/work/stderr*
-rw------- /usr/sap/NPL/ASCS0/work/sapstart0.trc
-rw------- /usr/sap/NPL/ASCS0/work/sapstart.log
-rw------- /usr/sap/NPL/ASCS0/work/sapstart.sem
-rw------- /usr/sap/NPL/ASCS0/work/sapcpe_sapcrypto.log
-rw------- /usr/sap/NPL/ASCS0/work/sapstart1.trc
-rw------- /usr/sap/NPL/ASCS0/work/sapcpe_scs.log
-rw------- /usr/sap/NPL/ASCS0/work/enquelog
-rw------- /usr/sap/NPL/ASCS0/work/sapstartsrv.log
-rw------- /usr/sap/NPL/ASCS0/work/history.glf
-rw------- /usr/sap/NPL/ASCS0/work/ENQLOG99
-rw------- /usr/sap/NPL/ASCS0/work/sapcpe_base.log
-rw------- /usr/sap/NPL/ASCS0/data/ENQSTAT
-rw------- /usr/sap/NPL/ASCS0/log/sapccmsr/agent.lock
-rw------- /usr/sap/NPL/ASCS0/log/sapccmsr/oscolfilter.ini
-rw------- /usr/sap/NPL/ASCS0/log/sapccmsr/sapccmsr.ini
-rw------- /usr/sap/NPL/ASCS0/log/sapccmsr/sapstartsrv_ccms.log
-rw------- /usr/sap/NPL/ASCS0/log/sapccmsr/logsave.bin
-rw------- /usr/sap/NPL/ASCS0/log/ENQBCK
-rw------- /usr/sap/NPL/D00/work/INSTSTAT
-rw------- /usr/sap/NPL/D00/work/stdout*
-rw------- /usr/sap/NPL/D00/work/gw_log-*
-rw------- /usr/sap/NPL/D00/work/available.log
-rw------- /usr/sap/NPL/D00/work/stderr*
-rw------- /usr/sap/NPL/D00/work/sapstart0.trc
-rw------- /usr/sap/NPL/D00/work/VMCavailable.log
-rw------- /usr/sap/NPL/D00/work/sapcpe.log
-rw------- /usr/sap/NPL/D00/work/sapstart.log
-rw------- /usr/sap/NPL/D00/work/sapcpe_cpe_sybjdbc.log
-rw------- /usr/sap/NPL/D00/work/sapstart4.trc
-rw------- /usr/sap/NPL/D00/work/sapcpe_cpe_sybodbc.log
-rw------- /usr/sap/NPL/D00/work/sapstart.sem
-rw------- /usr/sap/NPL/D00/work/stderr*
-rw------- /usr/sap/NPL/D00/work/sapcpe_sapcrypto.log
-rw------- /usr/sap/NPL/D00/work/disp+work.status
-rw------- /usr/sap/NPL/D00/work/sapstartsrv.log
-rw------- /usr/sap/NPL/D00/work/dev_rfc*
-rw------- /usr/sap/NPL/D00/work/history.glf
-rw------- /usr/sap/NPL/D00/work/sapcpe_base.log
-rw------- /usr/sap/NPL/D00/igs/log/bwgis_*.trc
-rw------- /usr/sap/NPL/D00/igs/log/imgconv_*.trc
-rw------- /usr/sap/NPL/D00/igs/log/xmlchart_*.trc
-rw------- /usr/sap/NPL/D00/igs/log/imgconv_*.trc
-rw------- /usr/sap/NPL/D00/igs/log/rspoconnector_*.trc
-rw------- /usr/sap/NPL/D00/igs/log/xmlchart_*.trc
-rw------- /usr/sap/NPL/D00/igs/log/rspoconnector_*.trc
-rw------- /usr/sap/NPL/D00/igs/log/chart_*.trc
-rw------- /usr/sap/NPL/D00/igs/log/bwgis_*.trc
-rw------- /usr/sap/NPL/D00/igs/log/chart_*.trc
-rw------- /usr/sap/NPL/D00/log/ALMTTREE
-rw------- /usr/sap/NPL/D00/log/ALAGENTALERTS
-rw------- /usr/sap/NPL/D00/log/ALPERFHI
-rw------- /usr/sap/NPL/D00/log/ALALERTS
-rw------- /usr/sap/NPL/D00/log/sapccm4x/agent.lock
-rw------- /usr/sap/NPL/D00/log/sapccm4x/oscolfilter.ini
-rw------- /usr/sap/NPL/D00/log/sapccm4x/sapccmsr.ini
-rw------- /usr/sap/NPL/D00/log/sapccm4x/sapstartsrv_ccms.log
-rw------- /usr/sap/NPL/D00/log/sapccm4x/logsave.bin

Okay thats a bunch of files, but in the relevant directories are even more files created. In my test system 95 files are created but just 63 suffer from the stricter umask. As a conclusion the parameter Service/umask does not cover all files created by NW AS ABAP.

 

install/umask

 

Default value: 007

With this parameter set to 077 the following files are created with adjusted permissions:

-rw------- /usr/sap/NPL/ASCS0/log/SLOG*
-rw------- /usr/sap/NPL/D00/log/SLOG*
-rw------- /usr/sap/NPL/D00/log/audit_*

At least the syslog and the SAL are covered which makes it worth considering to adjust the parameter.

SAP states that parameter install/umask can be overruled by parameter rdisp/umask, but does not give a reason for that, i suggest to set both parameters to the same value.

 

rdisp/umask

 

Default value: empty

With this parameter set to 077 the following files are created with adjusted permissions:

-rw------- /usr/sap/NPL/D00/work/dev_rfc*
-rw------- /usr/sap/NPL/D00/work/gw_log*
-rw------- /usr/sap/NPL/D00/work/VMCavailable.log
-rw------- /usr/sap/NPL/D00/work/disp+work.status

I’m curios why this affects also the rfc developer traces – remember dev_rfc* were already affected by service/umask – and why are all the other dev_* are not affected? Probably this can only be answered by SAP.

SAP states that parameter install/umask can be overruled by parameter rdisp/umask, but does not give a reason for that, i suggest to set both parameters to the same value.

 

Hmmm, what are these parameters for once again?

 

My testing was performed with the standard umask 022 set for OS user <sapsid>adm. So now let’s check what happens if the umask 077 is set for <sapsid>adm.

I compared the result when umask for <sapsid>adm is set to 077 on OS level and all relevant profile parameters are left at default values. As expected there is not much of a difference. The only file with stricter permissions than before is

-rw------- /usr/sap/NPL/D00/work/dev_tp

 

Analysing the result when umask on OS level is set to 077 and all relevant profile parameters are set to 077 i determined that the following files do not get adjusted permissions at all:

-rw-r--r--	/usr/sap/NPL/ASCS0/work/dev_enqadm
-rw-r--r--	/usr/sap/NPL/ASCS0/work/dev_enqio_*
-rw-r--r--	/usr/sap/NPL/ASCS0/work/dev_enqlisten
-rw-r--r--	/usr/sap/NPL/ASCS0/work/dev_enqsig
-rw-r--r--	/usr/sap/NPL/ASCS0/work/dev_enqsrv
-rw-r--r--	/usr/sap/NPL/ASCS0/work/dev_enqwork
-rw-r--r--	/usr/sap/NPL/ASCS0/work/dev_ms
-rw-r--r--	/usr/sap/NPL/ASCS0/work/dev_sapstart
-rwxr--r--	/usr/sap/NPL/ASCS0/work/kill.sap
-rwxr--r--	/usr/sap/NPL/ASCS0/work/shutdown.sap
-rw-rw----	/usr/sap/NPL/D00/data/PAGFIL00
-rw-r--r--	/usr/sap/NPL/D00/igs/log/mux_vhcalnplci.trc
-rw-r--r--	/usr/sap/NPL/D00/igs/log/pw_vhcalnplci_*.trc
-rw-r--r--	/usr/sap/NPL/D00/igs/log/wd_vhcalnplci.trc
-rw-r--r--	/usr/sap/NPL/D00/work/dev_disp
-rw-r--r--	/usr/sap/NPL/D00/work/dev_icm
-rw-r--r--	/usr/sap/NPL/D00/work/dev_icm_sec
-rw-r--r--	/usr/sap/NPL/D00/work/dev_rd
-rw-r--r--	/usr/sap/NPL/D00/work/dev_sapstart
-rw-r--r--	/usr/sap/NPL/D00/work/dev_w*
-rwxr--r--	/usr/sap/NPL/D00/work/kill.sap
-rwxr--r--	/usr/sap/NPL/D00/work/shutdown.sap

 

Try it the other way around

 

Maybe these parameters were meant to weaken certain file permissions if a strong umask is set for the OS user?

So i kept umask 077 for OS user <sidadm>adm but set all the relevant profile parameters to 022.

Now all files which have been affected by the profile parameters in my first test case are created with less restrictive permissions! Meaning the stricter umask from OS level is overwritten by the umask set in the relevant profile parameters.

For completeness, in this scenario the following file is still created with stricter permissions:

-rw------- /usr/sap/NPL/D00/work/dev_tp

So it seems this developer trace is written directly by TP and does not consider the profile parameters.

 

Let’s sum up

 

In SAP NW AS ABAP on Linux we have basically two options to affect the umask:

  • One is to adjust the umask of the <sid>adm on OS level,
  • the other is by adjusting profile parameters.

Based on your organisational structure SAP administrators may not be allowed to deal with the users settings on OS level. Furthermore, as proven the relevant profile parameters overrule the OS level umask in almost all cases.

So keep in mind:

  1. Setting the umask on OS level may lead to unexpected results if the relevant profile parameters remain untouched. Remember some of them have a kernel default value defined which may be more lax than the umask defined on OS level.
  2. Kernel tools like TP may not consider profile parameters.
  3. Consider to define a custom value for the profile parameters install/umask and rdisp/umask to protect the SAL and syslog.
  4. Consider to define a custom value for the profile parameter stat/umask to protect the statistic files.
  5. Changing the umask does generally not affect all files created by AS ABAP. SAP may use some additional, kernel internal mechanism to adjust the permissions of new created files besides simply relying on any defined umask, be it on OS level, be it through profile parameters.

 

It seems this statement is still valid (even one can think the answer to this question in the answer section of the SAP note is meant to be the solution):

[…]

Q: Under UNIX, the file authorization mask (umask) cannot be set consistently for all the processes of an instance, independently of the global settings. Either the <sid>adm or root umask is active depending on how sapstartsrv or the instance was started. You can only use the other parameters – such as rdisp/umask, stat/umask, and install/umask – to set umask for certain subareas (see the documentation of the respective parameters for more information).

[…]. SAP note 877795 – Problems with sapstartsrv from Release 7.00 and 6.40 patch 169

 

If someone has information why not all files are affected it would be great to share this in the comments.

 

Annex:

[1]

The documentation of the parameters is rather vague:

Parameter install/umask:

“Whenever files need to be created, the kernel often uses this mask to modify the permission bits intended for the file in question.”

“Parameter install/umask is in some cases only evaluated if rdisp/umask is not set.”

Parameter rdisp/umask:

“If the parameter is set, the parameter install/umask is ignored in some cases.

In some cases only rdisp/umask is used.”

 

References:

SAP note 1311885 – New profile parameter rdisp/umask

SAP note 68718 – Problems with file authorizations and umask

SAP note 88452 – CANNOT_DISASSEMBLE_R_DATA_FILE

SAP note 2153026 – FTP_FAILED when adjusting the import queue in STMS

1 Comment
You must be Logged on to comment or reply to a post.
  • It is unfortunate that the SAP kernel has a umask configuration item that clashes with the BASH shell built-in configuration item of the same name. I suspect it’s a source of great confusion in certain circumstances. I kind of wish they’d used a different name.

    In any event, my comment here is going to deal specifically with the umask property of the BASH shell environment (the information is also applicable, to one extent or another, in other shells; but the standard shell for SLES and RHEL is BASH)

    I’d like to call attention to a quote above (emphasis mine):

    Under UNIX, the file authorization mask (umask) cannot be set consistently for all the processes of an instance, independently of the global settings. Either the <sid>adm or root umask is active depending on how sapstartsrv or the instance was started.

    That quote is important; because umask is a property of the shell environment, its value depends a great deal on how the process was invoked, as well as the User ID (that is, the OS User ID) used to invoke it. Depending on the system configuration, a process invoked different ways, but under the same User ID, can have a different umask value for the shell. This occurs because BASH initialization follows different chains of initialization files depending on if the shell is a login or a non-login shell, and further if it is Interactive or non-Interactive.

    I could spend a lot of time writing about the differences, and even then I would probably not explain it all. If you’re an experienced SAP/BASIS admin, then unless you’re retraining to switch careers to Linux system management, it’s not worth getting into that patch of weeds. Sit down with your local friendly Linux systems expert, explain your concerns/objectives, and they should be able to design a configuration regime to meet your needs.

    Also worth highlighting is a specific part of the quote:

    ….<sid>adm or root umask is active depending on how sapstartsrv or the instance was started….

    That ambiguity is why it’s a good idea to start application processes as something other that root. There’s been plenty of times that I’ve caught various app installations blithely assuming there were no other applications on a host and modifying the shell initialization files for the whole system, or a system account like root, or even both. As often as not, something ended up breaking.

    Finally, with regard to using the SAP umask setting vs. the one affecting the BASH shell, I recommend choosing one or the other. Attempting to mix-n-match is likely to create problems.