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 profile 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), as well as files created by so called flat-file interfaces. These are not covered in my testings.
Analyze the impact of umask
Therefore, 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 which just extracts a running system, I had to cleanup some directories to have a fresh test environment:
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/*I will repeat this steps each time before I start a new test case.
Which umask might be suitable?
The umask defines what permissions will be masked from whatever the application specifies as the permissions when calling open() or mkdir(). Typically permissions 666 are used. From these
- umask 007 removes all permissions for others resulting in 660
- umask 027 additionally remove write permissions for group resulting in 640
- umask 077 removes all permissions for group and others resulting in 600
For my testing, I decided to use umask 077.
So lets start gather some data
- Perform the cleanup as listed above.
- Set one of the relevant parameters to 077 and start the system.
- Logon with SAPgui, perform some actions.
- Stop the system.
- Export a listing of all files and folders in /usr/sap/$SAPSYSTEMNAME/.
- Reset the parameter to its default value.
- Cleanup the files.
- 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*This parameter affects indeed only the statistic files.
Note: 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 log rotation they geht re-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.binHuhh! thats a bunch of files.
But in the relevant directories even more files are created. In my test system 95 files are created but 32 do not suffer from the stricter umask. For example, dev_enq*, dev_disp, dev_icm*, dev_ms, dev_rd, dev_sapstart, or dev_w* are not affected (see later on).
Note: I may spend some time in the future for double checking this by setting the umask for <sapsid>adm using pam_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 this parameter.
Note: SAP states that parameter
install/umaskcan be overruled by parameterrdisp/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.statusI’m curious why this affects also the dev_rfc developer traces – you can find dev_rfc* files also in the list of files affected by service/umask – and why are all the other dev_* are not affected?
Note: SAP states that parameter
install/umaskcan be overruled by parameterrdisp/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 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_tpThe reason for this may be that dev_tp is written directly by tp which does not consider the profile parameters.
For syslog and the SAL the default value 007 of install/umask took effect.
Analyzing the result when umask on OS level is set to 077 and all relevant profile parameters are also 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.sapNote: So again, I may spend some time in the future for double checking this by setting the umask for <sapsid>adm using pam_umask.
Try it the other way around
Can we use these parameters to weaken certain file permissions if a strong umask is set for the OS user?
To figure this out, I kept umask 077 for OS user <sidadm>adm but set all the profile parameters to 022.
Now all files which have been affected by the profile parameters in my previous test cases are created with less restrictive permissions! Meaning the stricter umask from OS level is overwritten (!?) by the umask set in the relevant 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 organizational 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.
Keep in mind:
- 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 less restrictive than the
umaskdefined on OS level. - Kernel tools like
tpmay not consider profile parameters. - Consider to define a custom value for the profile parameters
install/umaskandrdisp/umaskto protect the SAL and syslog. - Consider to define a custom value for the profile parameter
stat/umaskto protect the statistic files. - Changing the umask does not affect all files created by AS ABAP. SAP may use some additional, kernel internal mechanism (or the way how processes are started/forked) 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 the following statement is still valid (ignoring the answer to this question in the answer section of the SAP note):
[…]
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
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):
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:
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.