umask, setgid, and sticky bits

From: Scott Duckworth (scott@astnetworks.com)
Date: 08/15/02 

From: Scott Duckworth <scott@astnetworks.com>
Date: Wed, 14 Aug 2002 18:17:16 -0400

I am trying to figure out how I need to handle file permissions on my
server. The end result I am aiming for is to allow users that are in the
"music" group to be able to have full write access to all files and
directories in the /home/music directory, even to files and directories
that they did not create.

The user home diretories are located in /home/users with 750 permissions and
the owner is root:users. This is more or less normal I think.

The music directory is located at /home/music with 3775 permissions and the
owner is root:music. The 3 in the /home/music permissions is for the
setgid and sticky bits.

According to a link I found (*) the setgid bit on a directory makes "all
files created under it subsequently receive the group ID of that directory"
(so that if joe of the users group creates a file, it will have owner
joe:music instead of joe:users). I have found that this bit is inherited
by new directories but not new files (good).

According to the manpage on my computer, the sticky bit on a directory
"means that only the owner of the file and the owner of that directory may
remove the file from that directory" (I don't want anybody in the "music"
group removing /home/music itself). I have found that this bit is not
inherited by files or directories created within this directory (good).

With the umask set to 022 (set in /etc/profile), this gives me the correct
behavior for files in home directories (new file permissions are set to 644
and new directories are set to 755 and user is <user>:users). But when a
member of the "music" group makes a file or folder in /home/music, the same
thing happens, but the group is changed to "music". This keeps other
members of the "music" group from modifying the file/creating a new file in
the directory.

Changing the umask to 002 fixes the problem with the music directory
(default permissions of 664 for files and 775 for folders), but then files
and directories that a user makes in his/her home directory will be
writeable by all members of the "users" group.

I know I'm streching the limits of the standard UNIX file permissions, but
is there any way to do this without EA's and ACL's? I am using a ReiserFS
file system under kernel 2.4.19 and I would like to be able to do this
without using XFS (or similar), or anything that requires a kernel patch.
However, if I need to do this, I'd rather go ahead and do it now before the
partition is full of data.

...or should I just deal with it and leave the umask as 022 and make members
of the "music" group manually chmod their created files to 664 and folders
to 775?

Thank you so much for your help.

* http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?chmod+C 

-- 
Scott Duckworth
Computer engineering student and wanna-be know-it-all.  ;)

Relevant Pages

  • Re: Securing IIS IUSER
    ... so that these account are not effectively Users members, ... > I then explicitly granted it read permissions to the wwwroot, ... Before granting IUSER permission to read the files/folder, ... > are any of these permitting IUSER access to files and folders with "Users" ...
    (microsoft.public.windows.server.security)
  • Re: Folders security, permissions
    ... On two different folders, in the D: ... Owner is set to Administrators ... permissions and just have everything accessible to ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Create Permissions to previously made folder.
    ... if these folders are on an Exchange 5.5 server, ... owner permissions via the Exchadmin tool...or you can try pfdavadmin... ...
    (microsoft.public.exchange.admin)
  • Re: Shared folder security tab...Windows 2003 server
    ... A user that creates a file/folder will be the owner of such and be able to ... change permissions on them even if they have no explicit permissions. ... security tab on all the client computers. ... While this worked for local folders ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Permissions of Profiles directories
    ... to inherit permissions from its parent or not. ... again does that mean Deny Administrator ... Also it doesn't mention who the owner of the subdirectories ... Child folders Owner: ...
    (microsoft.public.windows.server.sbs)