Group ownership of SAS EG files

[cdsavage01]

SAS EG is not setting the group owner equal to the primary group of the user, it is using the first secondary group listed.  Is there a way to configure EG to use the current users primary group?

-rw-rw-r--  1 cs31713 netbacku    16384 Mar 18 14:53 person.sas7bdat

/cdsg/users/cs31713> id cs31713

uid=431713(cs31713) gid=300091(infra) groups=301793(netbacku),2000020170(cfds),2000020171(cfgbl),300091(infra)

The new file should be owned by gid=300091(infra)

[jakarman]

Please get more information on DAC profiles with Unix. SAS EG is doing nothing wiht that as it are those OS settings being leading.

Normal behavior is:

- ownership of new files is defined by Owner:prgip    

  existing files can keep the already set group.
- the permission is set according the active umask-setting.

  With SAS the umask is inherited from the key running the spawner not the one you see with SSH.

- the user can modify that group himself when he is member of that group.

- the user cannot modify the ownership (id) of a file. That is requiring root ownership, but root usage is to be avoided.

- When the gid bit of the directory is set the files are inherting the group setting of the directory

- When the stikcy-bit of the directory is set only files you are the owner or the owner of the directory can delete files

  This is pointing at a common misperception. Deleting files is not controlled by file-attributes but is coming from directory rights

Wat is the setting of rights on the directory?

Was the file already exisiting?

Wicht Unix version you are using?     

[cdsavage01 · Accepted solution]

SAS Support supplied the solution

Do you have methods=pam set in the file <SASHOME>/SASFoundation/9.3/utilities/bin/sasauth.conf?

If so, then in this same file find the line:

                # GROUP_NOCASE=FALSE

and edit it to appear as:

                 GROUP_NOCASE=TRUE

(that is, remove the comment, and ensure the value is set to TRUE).

Once this is done, you will need to restart the SAS ObjectSpawner process.

[jakarman]

Pam is for authentication (after indetfication). As Windows is not case sensitive and Unix is, there is a need for control 

38160 - GROUP_NOCASE, a sasauth configuration option for UNIX environments, enables case-insensitivi...

AIX is an exception in this as there also no need for PAM they are using LAM. That is is not supported on AIX is a result.

This is a different topic as the posted question was about file/directory rights.

Also that can be more complicated than just simple DAC settings.

Selinux: Chapter 49. Security and SELinux (having ACL)   

[Quentin]

Hi  Jaap,

Followup permission question.

Suppose I own a directory  /Dropbox  and make it: rwsrws---

So any file put in in that directory by any process will be owned by me (because uid is set), and the group will be set to the group of the directory (because gid is set).

Is there a way for me to say that any files put in there should also inherit the persmissions from the directory?   (rather than the umask of the process that puts the file there?)

That is, suppose some process is running with umask set as 000, and they write a file to /Dropbox, as I understand it the file would still be rwxrwxrwx.

Seems like the uid and gid biths allow me to specify that files should inherit group id and user id from the directory, but I can't actually specify that they inherit permissions from the directory, correct?

Thanks,

--Q.

[Quentin]

Well, I asked Google, and it said files can't inherit permissions from a directory, unless you have ACL's set up.

[jakarman]

Hi Quentin we extend this thread as belonging to the Original question.

This is nice, you showed a new kind of setting too me. The setuid at the directory level propagating the owner to the files.

I would like to know which Unix (Linux type/version) you have, as it is different at AIX. Help - AIX 6.1 Information Center .

The same differences can occur with the sticky-bit. As it supported at most OS-types Hadoop (until now) is uhh was an exception. Sticky bit - Wikipedia, the free encyclopedia and Step 13: Set the Sticky Bit on HDFS Directories

The execute bit on a directory has the meaning:  you can do a "change directory", by that you can set permissions in a way you hide the contents but for insiders allowing to cd a not visible directory.

The hierchal structure of folders/directories is adding a security hierarchy. Suppose you wat to create a dropbox like folder.  /public/postofficeQ/dropbox078  

/public defining rights as rwx r-x r-x   everybody can see folder postofficeQ 
/public/postofficeQ as Qmstr:Qmembr rwx r-x --- the master (priviledged key:Qmstr) has set this DAC-rights. Only members of the group Qmembr can go on en enter this folder nobody else

/public/postofficeQ/dropbox078 as recvr078:fam078  rwx rws rwt (setgid sticky-bit) (priviledged key:recr078 group:fam078)

With this construct:

- everybody that has access to postofficeQ is able to drop files in dropbox078 and the files wil get the associated group of the directory (no need for membership)

- When someone drops a file he can decide everybody else (umask others) rights, or just the group member fam078 (group rights)

- The posted files in dropbox078 only can be deleted  by the directory-owner recr078 or the poster (the owner of the file) himself

It is amazing and dazzling what you can achieve with DAC rights at the UNIX OS-level and at the same time how few people are capable to work with that.

One advice: do not trust security-specialists in this area, as they are often failing with this.

You are correct in not having found inheritance of acces rights of directory. They behavior is quite different is some aspects. I will not expect that.

But with the mentioned construct of a mailbox I think you are happy and the default umask of 027 will do marvelous.

Many other settings will be also accpetable evaluating impact/risk. 

When I got to notice in seeing this differences it were the ulimits umask and crontab(documented) with filetransfers sudo and SAS.

The settings of a forked proces are not set in the same way as you are working with SSH.  Some of those steps are not kernal bound but are looking to be scripted 9ssh)  at the login /start process event.

SAS is knowing that altough this knowledge is mostly lacking at TS support.38040 - Setting umask and ulimit values for SAS® sessions on UNIX and Linux    

[Quentin]

Thanks Jaap!

I like your /dropbox setup!

Still, as you say, this setup lets users their umask to give everyone else (or nobody else) rwx.

So if Albert has his umask set to rwxrwxrwx, he could drop a file in my drop box, and somebody else could revise the file, right?  (I think the sticky bit protects from having someone else delete or move the file).

So I can't say "if you put a file in my drop box, it will be safe from edits by others."  Of course I can say "if you put a file in my drop box, if you set the file permissions to be safe from others (rwx------) , it will stay safe from others", which is reasonable.  And I could always schedule a job to reset the permissions (since I would own the file).

THanks again for your detailed explanations and links.  These came at a timely moment for me, and led to much reading this morning.