LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Red Hat
User Name
Password
Red Hat This forum is for the discussion of Red Hat Linux.

Notices


Reply
  Search this Thread
Old 02-21-2011, 01:11 PM   #1
manyrootsofallevil
Member
 
Registered: Dec 2010
Distribution: Red Hat, Kubuntu
Posts: 130

Rep: Reputation: 14
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
Quote:
Create and configure set-GID directories for collaboration
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
 
Old 02-21-2011, 02:03 PM   #2
stress_junkie
Senior Member
 
Registered: Dec 2005
Location: Massachusetts, USA
Distribution: Ubuntu 10.04 and CentOS 5.5
Posts: 3,873

Rep: Reputation: 335Reputation: 335Reputation: 335Reputation: 335
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.

Last edited by stress_junkie; 02-21-2011 at 04:30 PM.
 
1 members found this post helpful.
Old 02-22-2011, 01:51 AM   #3
manyrootsofallevil
Member
 
Registered: Dec 2010
Distribution: Red Hat, Kubuntu
Posts: 130

Original Poster
Rep: Reputation: 14
Quote:
Originally Posted by stress_junkie View Post
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.
 
Old 03-03-2011, 04:15 PM   #4
manyrootsofallevil
Member
 
Registered: Dec 2010
Distribution: Red Hat, Kubuntu
Posts: 130

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

Quote:
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
umask 006
else
umask 022
fi
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
 
Old 10-16-2011, 11:42 AM   #5
anon011
LQ Newbie
 
Registered: Oct 2011
Posts: 1

Rep: Reputation: Disabled
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
file permissions with Set GID cylon Linux - Newbie 2 09-16-2009 06:49 PM
Default GID Not Being Set carlosinfl Red Hat 2 10-04-2007 05:55 PM
set gid problem gw1500se Mandriva 2 04-09-2007 02:54 PM
set gid linuxtesting2 Solaris / OpenSolaris 2 06-18-2006 02:18 PM
mounting an iso9660 with uid and gid set to user cwin Linux - Software 3 12-22-2004 05:45 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Red Hat

All times are GMT -5. The time now is 08:30 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration