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.




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.




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 and rdisp/umask


Default value: 007 (install/umask), empty (rdisp/umask)

Since SAP states that parameter install/umask can be overruled by parameter rdisp/umask, but does not give a reason for that, i decided to set both parameters together as recommended for example in SAP note 2665893.

With these parameters set to 077 (without setting service/umask in any profile) the following files are created with adjusted permissions:

-rw------- /usr/sap/NPL/ASCS0/log/SLOG*
-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
-rw------- /usr/sap/NPL/D00/log/SLOG*
-rw------- /usr/sap/NPL/D00/log/audit_*

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.

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


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 npladm.

I compared the result of umask set on OS level to 077 and profile parameters not set to custom values.

As expected there is not much of a difference to the testcase where service/umask was set to 077. The only file with stricter permissions than before is

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



Analyzing the result of umask set on OS level to 077 and all profile parameters 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/
-rwxr--r--	/usr/sap/NPL/ASCS0/work/
-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/
-rwxr--r--	/usr/sap/NPL/D00/work/


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 npladm but set all the parameters to 022. And effectively all files which have been affected by the profile parameters in my first tests are now created with less restrictive permissions.

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

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


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. Setting the umask on OS level may lead to unexpected results if profile parameters remain untouched since some of them have a kernel default value defined. Changing the umask to 077 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 the umask.

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

So it seems this statement is still valid (even one can think the given answer 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





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.”



SAP note 1311885 – New profile parameter rdisp/umask

SAP note 68718 – Problems with file authorizations and umask


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

Be the first to leave a comment
You must be Logged on to comment or reply to a post.