BookmarkSubscribeRSS Feed
Ram4sas
Fluorite | Level 6

Hi All,

i am trying to find out the solution for below Unix folder security implementation.

The SAS EBI servers configured on Unix OS and been configured with LDAP for authentication(for groups and user).

1. Users been added into individual LDAP Groups as required.

2. Folder structure created in UNIX for each Group and granted own ownership to each group.

3. User home directiry been mapped to each own group folders.

Power users are having access multiple group folders, power user wants to copy/paste the files/folder into different group Unix folder so that own group users should be able to read that files.

Example: Power user moved one folder called CODE(the folder contain file - test.sas) from 'SALES' to 'MARKET' Unix folder to use by MARKET group users.

But the CODE folder permissions are RWXRWX--- and MARKET group users cannot open and getting "permission denied" message.

if i apply the permission R-X on CODE folder for MARKET Group then MARKET group user are able to see.

But User done want this to happen always seeking permission apply when Power user moved the files and apply the permission.

Can someone suggest how to implement above folder permission more elegant solution?

Thanks,

Ram

11 REPLIES 11
Tom
Super User Tom
Super User

You need to set the group sticky bit so that new files and folders copied into the folders will be in the right GROUP.

So the permissions on the SALES folder with will be rwxrws--- and the group will be "sales'.  If PowerUser1 tries to create a folder name SALES/code then the folder will be owned by "sales" group instead of their default group.

You also probably need to look at the UMASK setting so that files/directories are created with the group write bit set.  Otherwise only the user that created the folder will be able modify directory entries (create or delete files).

Anand_V
Ammonite | Level 13

Hi,

Make sure the user trying to copy the file has a secondary group defined as well apart from primary group.

As per your example above, Power user is trying to copy the file 'test.sas' from DIRECTORY Code, which is owned by group 'SALES' . So I assume here that the user has 'SALES' as primary group. So add 'MARKET' has the secondary group to this user and then try to copy and execute the file.

In order to check the user Primary and secondary group you can use the below command in unix:

[ unix prompt ] $ id <userid>

Incase you dont have root or elevated privileges you need to ask your unix system admin to do the above.

Thanks!

Ram4sas
Fluorite | Level 6

Hi All.

The Power User is member of SALES and MARKET group, that'swhy  he is able to copy/paste the CODE folder from SALES to MARKET Folder.

the intention is to provide authorized access to MARKET group users on CODE folder files after copied by Power user.

I have verified using  [ unix prompt ] $ id <userid>

the power user is member of both groups. but still Market group users cannot open the CODE folder under Market folder which got created by power user.

Thanks,

Ram

Anand_V
Ammonite | Level 13

can you share what are the permissions defined for the market folder and code folder?
Thanks!

Ram4sas
Fluorite | Level 6

Hi ChrisPope,

the permission on for Market and CODE folder are:

Market:

drwxrwx---   sassrv    market(Group)   date time  Market(Folder)

Code:

drwxrwx--- 0101(poweruser ID)   sales(Power user Primary Group)    date time  CODE

Thanks,

Ram

ronan
Lapis Lazuli | Level 10

Tom's anwser above will guide you to a possible solution. In addition to this, you will need to set up umask profiles more "permissive" than usual and rely on secondary group membership.

I translate your specs in a few short sentences:

1. users from MARKET group are only allowed to create/purge/modify their own folders and files

2. user from SALES group are only allowed to create/purge/modify their own folders and files

3. POWER users are allowed to create/purge/modify any folder or files regardless of its owner/author

Here are the permissions settings your will need :

a. default umask value 002 for each user account on UNIX (~/.profile usually)

b. MARKET users have as primary group = MARKET, secondary groups = GXCHANGE

c. SALEs users have as primary group = SALES, secondary groups = GXCHANGE

d. POWER user have as primary group= POWER, secondary groups= GXCHANGE, MARKET, SALES

e. a two-level hierarchy of folder with a SetGID permission on the lower level (chmod 2775)

The corresponding tree structure, empty. POSIX permission profile is also displayed in octal :

<root folder>

|-- [drwxr-x--- 750,root     MARKET  ]  market

|   `-- [drwxrwsr-x 2775,user_mar GXCHANGE]  sasfolder

`-- [drwxr-x--- 750,root     SALES   ]  sales

    `-- [drwxrwsr-x 2775 user_sales GXCHANGE]  sasfolder

Each MARKET or SALES group can access only its own root folder, called "sasfolder". Parent folders 'market' or 'sales' are read-only as a security against any mishap.

Now, the tree in full blossom. A SetGID permission on a folder acts a little bit like an inheritance rule (NTFS) and propagates the (write) permission and ownership on every child folder.

.

|-- [drwxr-x--- root     MARKET  ]  market

|   `-- [drwxrwsr-x user_mar GXCHANGE]  sasfolder

|       |-- [drwxrwsr-x user_ful GXCHANGE]  myfolder_power  # sub-folder initially created by POWER users

|       |   `-- [-rw-rw-r-- user_ful GXCHANGE]  code.sas #initially created by POWER users

|       |-- [-rw-rw-r-- user_mar GXCHANGE]  mytable #initially created by MARKET users

|       `-- [-rw-rw-r-- user_ful GXCHANGE]  mytable_power #initially created by POWER users

`-- [drwxr-x--- root     SALES   ]  sales

    `-- [drwxrwsr-x user_sal GXCHANGE]  sasfolder

        |-- [drwxrwsr-x user_ful GXCHANGE]  myfolder_power

        |   `-- [-rw-rw-r-- user_ful GXCHANGE]  code.sas

        |-- [-rw-rw-r-- user_sal GXCHANGE]  mytable

        `-- [-rw-rw-r-- user_ful GXCHANGE]  mytable_power

Be careful with such implementations, sometimes Unix system admin are not very familiar with special POSIX permissions (SetUID, SetGID, sticky bit).

Ram4sas
Fluorite | Level 6

Hi Ronan,

I have to clarify one thing here that there is no group called 'POWER'. the user who has access to multiple groups in LDAP and folders in Unix machine calling as power user.

the power user been added into multiple groups in Ldap server then established links to all group folders in Unix as for each group one separate folder been created.

is above set up can be implemented for my system? what is GXCHANGE folder for?

Can i create that in Unix without group in LDAP?

Thanks,

Ram

ronan
Lapis Lazuli | Level 10

I have used POWER as a mere placeholder for the power users primary group, which is mandatory. Of course, it might be called differently in your system.

Secondary groups are optional for the system (but not in this example !).

I have tested - quickly - this scheme on a Linux machine but I assume it can also be applied as is on Unix as well.

The trees I have shown are created with the following command (availability may vary) :

tree -pagu

GXCHANGE (I have written groups with upper case letters) is a group used as a 'pivot'. You can name it as you like. It enables sharing the same folder/files amongst several different accounts.

The access to the GXCHANGE group comes with secondary memberships : the user accounts in your directory can have multiple secondary groups, distinct from the primary group.

The Unix command to display primary and secondary groups for a given user account is  :

id <username>

if <username> is omitted then it displays the groups for the terminal owner.

I strongly advise against maintaining groups both locally (/etc/group) and externally ('LDAP'). It's not necessary to implement a permission policy like this one above.

Astounding
PROC Star

Unix has a chgrp command that lets you change file ownership at the group level.  That might be tedious, but it should give you the tools you need (in combination with chmod) ... maybe.

One group functions as the individual owner, the other as the group owner, with chmod setting different permissions for each.

bentleyj1
Quartz | Level 8

This sounds to me a bit like a problem we had years ago... we needed to assign permissions to a subset of a Group but didn't want to create a new Group because the SysAdmins said they were already borderline unmanageable.

Unix/Linux has a feature/capability called File Access Control Lists that sort of over-ride the Group permissions on a user-specific basis.  Although it has 'File' in the name they can be set at the directory level.  Here are a links to a couple useful pages.  One page says that they can be complicated but that wasn't our experience maybe because the SysAdmins allowed us to maintain our own ACLs.

"ACLs increase the level of complexity by an  order of magnitude which put full understanding of this model beyond regular sysadmin intellectual capabilities."

Look at the 'basics' link first.  Good luck!

UNIX/Linux : Access control lists (ACLs) basics

Unix Access Control Lists (ACL)

(sorry, I can't figure out how to make it display the web address.)

jakarman
Barite | Level 11

You need to understand how Unix DAC (Discrete Access Control) security is working in a HFS (Hierarchical Files system).

The other one is the role the "Owner" has in that Unix security concept and I would not bother too much on ACL's Jerks and confinement (SElinux) no having those.

The remarks:

- ACL's looks more convenient as the similarity to Windows. They are unreliable as the access check can disappear unexpected. the goals is a fixes not changing environment.

- Jerks is the idea you can limit access rights by granting them to additional groups

- Selinux is delivering the containerization you can find with Docker (and SAS-VA).

The maximum numbers of groups on a Linux/Unix system was once a problem (Posix-8 BSD-16). Windows for a long time far better with 1020.         

Check that number with ngroups_max limits.h https://www.j3e.de/ngroups.html  As modern systems are above that old low limit that should be no problem anymore. One exception is the NFS system. 

Some nice papers on DAC are:  part 1 Hacking Linux Exposed  part 2  Hacking Linux Exposed  

For a sharing and isolation strategy you need to design your hierarchy

What must be able to be shared should be in the same hierarchy, what should be isolated must be in separated trees.

The idea is starting a full read/execute access (directories) and than limiting the directories in still further refinements. The reason: all access of the complete hierarchy every level counts and cannot be bypassed. This is needing to switch your mind as the initiation is only seeing the current directory  (wrong!).

The owner of directories/folders is for the best done with a privileged key (functional account)  or you will sooner or later running get into problems. I don not see the setting the owner-group?

For the DAC rights owner/group/other only one of the tree will evaluated, not all.

For changing to a directory you need a Execute grant for that directory

For moving/deleting files you need write access to the directory.  No, no grants on the file itself as it is only a registration in the directory.  (Often being faulty interpreted). To have only the owner of the directory or the owner of the directory doing a delete/move you need to set the sticky bit on the directory.  The bad thing is, you will see a differentiation in DAC rights of files and directories. It is how -Nix systems DAC are working. 

Having files being created by users, the primary group of the user will be set to the file. That is not necessary the same as the group of the directory. To have the files the same group as the directory set the groupid on the directory.  There is no need the user processing a file in that directory is a member of that group.

Your elegant approach request looks like wanting to have a file dropping zone.

Create a dedicated directory as a marketing dropping zone   eg:  .../drpbx/marketing     Set the group to marketing , Set the DAC rights as 3777 (sticky bit and groupid bit)

- Anybody having access to drpbx can post files in that marketing directory (you can limit the usage by using a dedicated group on drpx)    

- The files will be able to be accessed by the marketing group and the owner of the file. The owner of the file will have to set those rights 

- the "owner" of the directory marketing can delete files when dacs (chmod)  for the user/group are wrong.   

 
      

---->-- ja karman --<-----

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 11 replies
  • 7055 views
  • 0 likes
  • 7 in conversation