How-to set group permissions on unix folders to allow files shared by multiples users and systems

It is a very common requirement to have a shared Unix file system to share and process application related data in SAP environments.

Scenario: SAP and ETL application development teams have decided to build file based interfaces. In this particular case we are implementing interfaces between SAP and ETL.

The basic requirements are as follows: SAP needs to be able to write files that ETL can read/delete and visa-versa ETL needs to write files that SAP can read/delete. Both servers are running UNIX.

High level outline of process:

1. Define Example Landscape
2. Create An Integration File System
3. Export File System and Mount
4. Example Issues / Scenarios
5. Creating A New UNIX Group
6. Set Integration Directory Group Ownership and Permissions
7. Adjusting The Umask

Define Examples SAP and JD Edwards Landscape

In our example, we have an SAP development system with SAPSID ECD . we will call this system SAPECD. We also have a ETL development system that we will call ETLDEV. In this example, we will only discuss the steps to integrate the two development servers. You will need to repeat this process and/or modify this process to configure the rest of your landscape.

Recommendations: It is not a common/good practice to share production mount points with DEV and QA systems.

Also, limit NFS exports of these filesystems, have a job running from each remote server/application to push/pull data from centralized application. For example, instead of exporting and mounting this file system on 3 or more servers, have the remote applications push/pull the data using sftp from SAP server or ETL server when you have need to share this file system with multiple applications running on multiple servers.

Creating An Integration File System

The first step in this process is to request to create a separate physical file system for your interfaces to use. This file system is to be separate from the OS, SAP kernel, and SAP database.

This is a very important step of the process. If it not a separate file system, we run into out of space, it could impact runtime environment of  business critical applications and these application may stop responding to users.  

The size of the file system certainly depends on a lot of project specific variables. In general, a 10 gig file system should be a good starting point (or larger if getting extra storage allocated requires several

management approvals)  for most SAP and other projects. However, an in-depth analysis is required to determine an appropriate amount of storage.

Export File System and Mount

In our example, we have created a 10 gigabyte file system for the interfaces and have mounted it to the root of the SAPECD server as the folder /transfer. We have exported this folder from the SAPECD host and created an NFS mount to the root of the EDLDEV server as the folder /transfer. Our servers now have a shared file system between them.

Example Issues / Scenarios

It  has been a pretty straight forward exercise so far in this example. Now we have to assign appropriate ownership, group and permission bits so each server has the correct permissions to read and write to the files.

ls –ld /transfer

drwxrwxrwx ecdadm sapsys 96 Sep 25 10:23 /transfer

If your permissions are set as above with read,write,execute for all, it is a very bad practice and it exposes your files to all users and you do not have protection for your data.

This will completely open up the permission on this directory.

In this example the mount point/directory is owned by SAP admin user account ecdadm. This user account has a primary group of sapsys. The permissions on this directory are set to allow any user in any group to read, write, and execute from this directory.

When an ABAP program is developed to write a file, it will always write the file with the ecdadm account (ecdadm in our example). When a file is written, it will use the default umask for the user to set the file’s permissions. If we were to write an interface file to /transfer it would look something like this in UNIX.

On SAPECD server, ls  -l  /transfer

-rw-r--r--  ecdadm  sapsys  256  96 Sep 25 10:28 sap_interface_file.txt

When a ETL program is developed to write a file, it will always write the file with the etladm account. Like SAP, when the file is written it will use the default umask for the user to set the file’s permissions. If we were to write an interface file to /transfer on ETL it would look something like this in UNIX.

On ETLDEV server,  ls –l /transfer

-rw-r--r--  etladm  etladm  256  Sep 25 2009  etl_interface_file.txt

-rw-r--r--  ecdadm  sapsys  256  Sep 25 2009  sap_interface_file.txt

We now have two files in the directory. If you list the contents of the directory on either server you will see the two files.

ls –l /transfer

-rw-r--r--  etladm  etladm  256  Sep 25 2009  etl_interface_file.txt

-rw-r--r--  ecdadm  sapsys  256  Sep 25 2009  sap_interface_file.txt

Simply mounting a file system between the SAP and ETL servvers is not enough to share files. Neither ecdadm or etladm can update, move, or delete the file written by the other server. Specifically, sap_interface_file.txt has -rw-r–r– for its permissions etladm can open and read this file but can not change it.

Most SAP integration scenarios that are file based read the file and then archive/delete it. The same issue is true for etl_interface_file.txt ecdadm can open and read this file but can not change it.

An Easy way out to solve this issue is  to add etladm to sapsys group and ecdadm to the etladm group. However, this is not a good practice from a security perspective. This would give the ETL admin authorization to SAP and SAP admin authorization to ETL.

More Secure – Scenario

Create a new UNIX group on both servers to own the /transfer folder, add both ecdadm and etladm as secondary group members, adjust the users umasks, and set the GID bit on the folder.

Let’s Create A New UNIX Group

In our example lets call the group “transfer”. We need to add both ecdadm and etladm added to this group as a secondary group; although they both keep their primary groups, sapsys and etladm respectively.

The group file contains all the groups configured for a server. In my example, I am going to assume that there is no central user configuration on your UNIX servers. Therefore, when this group is created on both the SAP and ETL server it is important that it is created with the same Group ID. It is important that you pick a Group ID that is not used on either server.

For this example we will use the group ID 300.

Entry in /etc/group file

transfer:*:300:

Set The Integration Directories Group Ownership and Permissions

Next, we need to change the ownership on the /transfer folder to have the owner group be “transfer” and not “sapsys”.

ls –ld /transfer

drwxrwxrwx ecdadm sapsys 1000 Sep 25 2009   /transfer

To change the ownership we run the UNIX command:

chown :transfer /transfer    OR   chgrp  transfer /transfer

ls –ld /transfer

drwxrwxrwx ecdadm transfer 1000 Sep 25 2009   /transfer

Notice the group is now “transfer”, not “sapsys”.

Next, we need to change the permissions on the /transfer folder to something a bit more secure, as well as set the GID bit. From UNIX issue the following command:

chmod 2770 /transfer

ls -ld   /transfer

drwxrws--- ecdadm transfer 1000 Sep 25 2009   /transfer

Notice the “s”; that is the GID bit. Setting this bit will force all files to adopt the group ownership of the parent directory not the primary group of the user.

Let’s write another file from SAP and ETL and check that file’ permissions. From UNIX issue the following command after writting a file from SAP and ETL to the /transfer directory.

ls –ltr    /transfer

-rw-r--r--  etladm  etladm  256  Sep 25 2009    etl_interface_file.txt

-rw-r--r--  ecdadm  sapsys  256  Sep 25 2009    sap_interface_file.txt

-rw-r--r--  ecdadm  transfer  256  Sep 25 2009  sap_interface_file._2.txt

-rw-r--r--  etladm  transfer  256  Sep 25 2009  etl_interface_file_2.txt

Notice the group on both files is now “transfer”. However, we have still not fixed our problem because both files were created with 644 permissions. We need our permissions to be 664 for every file written to this directory. We will, therefore, need to adjust the UMASK for ecdadm and etladm.

Adjusting The UMASK

To determine the UMASK to use, you must take the permission you want and subtract it from 777 to get your mask. In our case we would like the files to have 664 permissions.

777 – 664 = 113

You will need to set the UMASK to 113 for both ecdadm and etladm.

Let’s write another file from SAP and ETL and check those files out. From UNIX, issue the following command after writting a file from SAP and ETL to the /transfer directory.

ls –ltr  /transfer

-rw-r--r--  etladm  etladm    256  Sep 25 2009   etl_interface_file.txt

-rw-r--r--  ecdadm  sapsys    256  Sep 25 2009   sap_interface_file.txt

-rw-r--r--  ecdadm  transfer  256  Sep 25 2009   sap_interface_file._2.txt

-rw-r--r--  etladm  transfer  256  Sep 25 2009   etl_interface_file_2.txt

-rw-rw-r--  ecdadm  transfer  256  Sep 25 2009   sap_interface_file._3.txt

-rw-rw-r--  etladm  transfer  256  Sep 25 2009   etl_interface_file_3.txt