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

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. Reset the parameter to its default value.
7. Cleanup the files.
8. 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.bin

Huhh! 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/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 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/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 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

The 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.sap

Note: 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:

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 less restrictive 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 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.

A possible solution for using a strict umask while having flatfile interfaces where files are written from ABAP to disk and need broader permissions may be the following:

On Linux systems there is the utility setfacl. Once the mount option acl is set on the mountpoint where those files should be stored, whith this utility the permissions could

be adjusted on folder level at writing time. This would be a better solution instead of weakening the permission for every file written by the ABAP Kernel.

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