Create and configure set-GID directories for collaboration
 

I'm studying for the RHCSA certification (Tautology?) and I'm struggling a bit with this objective I've followed the instructions on the deployment guide (except that I created a different directory):

http://docs.redhat.com/docs/en-US/Re...ers_and_Groups

Yet, whenever I create a file in this new directory (logged in as a member of the owning group), permissions are set to 644, so other group members cannot edit the files.

I checked the umask value and it's set to 0022 and the permissions on the directory are set to 2775

Am I missing something here? Is this by design?

TIA

Referring to section 15.5.1 on the web page that you referenced:

Given a permission string of 2775 on /groupdir which is owned by user root and group testgroup

and given two user accounts, test1 and test2 which have group membership in testgroup as a secondary group for each user account

that page is saying that when either user (test1 or test2) creates a file in /groupdir that file's group ownership will be testgroup. The 2 in 2775 determines this.

The remaining three permission bits on the directory determine the access to the directory. The first 7 says that the directory owner has full read-write-execute permission on the directory. The second 7 says that members of the group testgroup have full read-write-execute permission on the directory. The remaining 5 says that anyone else has read-execute permission on the directory. These permissions DO NOT apply to the files in the directory. Each file in the directory can have its own permissions.

Note also that execute permission on a directory means that a user can see the names of the files in the directory along with their permission strings, size, etc. but not necessarily the contents of those files. The execution permission on the directory does not mean that the directory or the files in it can be executed in the way that one would execute a program.

So if someone has permission to create a file in that directory it will automatically be assigned group ownership of testgroup. However the umask of the user account that creates the file will determine the permissions on the file that is created.

Is that helpful? This can be a bit difficult to learn but eventually it will become clear.

I was going to update my post saying that in RHEL5, this was working, which it was(is), but the point is the user umask, which in my RHEL6 box is set to 0022 for the test users, whereas in my RHEL5 box, the test users have 0002, explaining why the files get created with 664 permissions.

I had not realized that the umask value was user specific.

At any rate, thanks for your post, very informative.

I was having a further look at this and I had a look at /etc/bashrc, where the first useful lines has this:

The thing is in my previous attempt I had used users I had been experimenting on, so that the users had different primary groups, which means that they would have got a umask of 0022.

I created a new user and this time a left the primary group alone and made it a member of the shared group as a supplementary group (usermod -G sharedgroup testuser) and it now gets a umask of 0006, so that files are created as 664 and are writable by other members of the shared group.

Now, I just need to understand why changing the primary group necessitate a change in umask

Found this thread via google, I have relevant information which should justify the necro-bump. When doing some experimentation with the 'how-to' in the second post, I found that adding the current, logged-in user to a group using a 'usermod -[a]G <supplemental group> <username>', the change in group membership does not take effect until the user is logged out and logged back in again.

In my case I have a remote server with a limited user strictly for logons, and was have a hell of time figuring out why I couldn't add a file to the directory owned by the supplemental group. Verify using the 'id' command as the current user, not 'id [<username>]'.

Note - Use of the -a flag with 'usermod' command above is optional, but good if you don't want to wipe out all other supplementary groups if you have any.