Re: ACLs, umask and shared directories
Hi Gary, Parts of the filesystem are written by all users - /tmp and /var/tmp. Users don't often write files there deliberately, but many programs run by the user do. With a umask of 002, one user can modify another user's file in these locations. (The sticky bit only protects against file deletion.) Also note that a user can change permissions on their home directory - the users in question are students, and a few do this accidentally every semester. With a umask of 002, and every user in the same group, your home directory is effectively world-writable! The cronjobs and so forth would work - but functional ACLs would be so much simpler :-) Thanks Rob. On 12/03/2010, at 12:52 AM, Gary Gatten wrote: Project Groups are the key. A secondary group owns the dir, only users working on that project are in that group - so 002 works. I get umask is system wide, but it should be ok if directory ownership is correct everywhere in the system and/or users know they should only put certain files in certain places. If for some reason that won't work (if you could explain why for my benefit) what about: A cron job that runs every x mins and sets perms as you wish. Ideally a daemon process would monitor the directory in question looking for opens/writes/etc, and then set perms; event driven. Lasty, maybe train the users to set perms, or have a script they can run that will do it. OR, have them create files in a temp dir and a cron job mv's them to the permanent dir and sets perms the same time? - Original Message - From: Rob list...@deathbeforedecaf.net To: Gary Gatten Cc: freebsd-questions@freebsd.org freebsd-questions@freebsd.org Sent: Thu Mar 11 05:04:28 2010 Subject: Re: ACLs, umask and shared directories Hi Gary, Directory group inheritance is the default in FreeBSD - see open(2): When a new file is created it is given the group of the directory which contains it. In SysV, this behaviour is controlled by the setgid bit. So the file has the correct group, but it's not writeable by other users unless it has g+w permissions. The way to guarantee this is to set everyone's umask to 002 - but then they can write each other's files anywhere else in the filesystem, because they're all in the same primary group. I just can't see a tidy solution. Thanks Rob. On 09/03/2010, at 10:34 AM, Gary Gatten wrote: chmod g+s ParentDirectory Files created in the dir now have the group of the dir. Not sure if this will help or not, as it appears the new files do not inherit the perms of the group, the umask still over-rides so What about a secondary group + SGID + umask 002? The users that need to edit each others files in this directory are in a secondary group (ShareMe). This same group owns the parent directory and the SGID bit is set. This should allow you to set the umask to 002 correct? Maybe? So: www1 primary group = domain_users; www1$ pwd /WorkgroupXShare drwxrws--- 4 root ShareMe 0 Mar 8 03:11 . www1$ touch file1 drwxrws--- 4 www1 ShareMe 0 Mar 8 03:11 file1 umask of 002 should give files 664 (I'd change umask to 004, group ShareMe should get rw perms, right? I think this will work? G -Original Message- From: Gary Gatten Sent: Monday, March 08, 2010 4:49 PM To: 'list...@deathbeforedecaf.net' Subject: RE: ACLs, umask and shared directories This may also work: SGID (set group ID) on a directory: in this special case every file created in the directory will have the same group owner as the directory itself (while normal behavior would be that new files are owned by the users who create them). This way, users don't need to worry about file ownership when sharing directories: G -Original Message- From: Gary Gatten Sent: Monday, March 08, 2010 4:13 PM To: Gary Gatten; 'list...@deathbeforedecaf.net' Subject: RE: ACLs, umask and shared directories What about sticky bit on the parent directory - in combination with appropriate owner and group perms. I used sticky in my ftpd solution, HOWEVER, this was on SCO Unix and sticky may have different behavior on FBSD. Worth a look though! G -Original Message- From: Gary Gatten Sent: Monday, March 08, 2010 8:25 AM To: 'list...@deathbeforedecaf.net' Subject: Re: ACLs, umask and shared directories I ran into a similar issue long ago with an ftp folder and shared files. If I recall umask solved my issue for me but understand it doesn't solve yours. If nothing else, could you write a shell script that monitors the directory/directories for writes and then sets the perms as needed? - Original Message - From: owner-freebsd-questi...@freebsd.org owner-freebsd-questi...@freebsd.org To: freebsd-questions@freebsd.org freebsd-questions@freebsd.org Sent: Mon Mar 08 06:41:03 2010 Subject: ACLs
Re: ACLs, umask and shared directories
Hi Gary, Directory group inheritance is the default in FreeBSD - see open(2): When a new file is created it is given the group of the directory which contains it. In SysV, this behaviour is controlled by the setgid bit. So the file has the correct group, but it's not writeable by other users unless it has g+w permissions. The way to guarantee this is to set everyone's umask to 002 - but then they can write each other's files anywhere else in the filesystem, because they're all in the same primary group. I just can't see a tidy solution. Thanks Rob. On 09/03/2010, at 10:34 AM, Gary Gatten wrote: chmod g+s ParentDirectory Files created in the dir now have the group of the dir. Not sure if this will help or not, as it appears the new files do not inherit the perms of the group, the umask still over-rides so What about a secondary group + SGID + umask 002? The users that need to edit each others files in this directory are in a secondary group (ShareMe). This same group owns the parent directory and the SGID bit is set. This should allow you to set the umask to 002 correct? Maybe? So: www1 primary group = domain_users; www1$ pwd /WorkgroupXShare drwxrws--- 4 root ShareMe 0 Mar 8 03:11 . www1$ touch file1 drwxrws--- 4 www1 ShareMe 0 Mar 8 03:11 file1 umask of 002 should give files 664 (I'd change umask to 004, group ShareMe should get rw perms, right? I think this will work? G -Original Message- From: Gary Gatten Sent: Monday, March 08, 2010 4:49 PM To: 'list...@deathbeforedecaf.net' Subject: RE: ACLs, umask and shared directories This may also work: SGID (set group ID) on a directory: in this special case every file created in the directory will have the same group owner as the directory itself (while normal behavior would be that new files are owned by the users who create them). This way, users don't need to worry about file ownership when sharing directories: G -Original Message- From: Gary Gatten Sent: Monday, March 08, 2010 4:13 PM To: Gary Gatten; 'list...@deathbeforedecaf.net' Subject: RE: ACLs, umask and shared directories What about sticky bit on the parent directory - in combination with appropriate owner and group perms. I used sticky in my ftpd solution, HOWEVER, this was on SCO Unix and sticky may have different behavior on FBSD. Worth a look though! G -Original Message- From: Gary Gatten Sent: Monday, March 08, 2010 8:25 AM To: 'list...@deathbeforedecaf.net' Subject: Re: ACLs, umask and shared directories I ran into a similar issue long ago with an ftp folder and shared files. If I recall umask solved my issue for me but understand it doesn't solve yours. If nothing else, could you write a shell script that monitors the directory/directories for writes and then sets the perms as needed? - Original Message - From: owner-freebsd-questi...@freebsd.org owner-freebsd-questi...@freebsd.org To: freebsd-questions@freebsd.org freebsd-questions@freebsd.org Sent: Mon Mar 08 06:41:03 2010 Subject: ACLs, umask and shared directories Hi Folks, I need to give a group of users write access to a shared directory. The problem is, when one user creates a file, www1$ touch file1 www1$ ll total 8 drwxrwxr-x 2 root domain_users 512 Mar 8 03:11 . drwxr-xr-x 4 root wheel 512 Mar 8 03:10 .. -rw-r--r-- 1 www1 domain_users0 Mar 8 03:11 file1 other users can't edit it. Solution 1 -- Change everyone's umask to 002. Unfortunately, these users are defined in Active Directory and they're all in the same primary group - 002 is not secure in this scenario. Solution 2 -- Set a default ACL on the parent directory, www1$ getfacl -d . # file: . # owner: root # group: domain_users user::rwx group::rwx mask::rwx other::r-x but it doesn't have the desired effect, www1$ touch file1 www1$ getfacl file1 # file: file1 # owner: www1 # group: domain_users user::rw- group::rwx # effective: r-- mask::r-- other::r-- as the umask seems to override it - this was confirmed by Robert Watson[1] in 2005. So does anyone have a better idea? Thanks Rob. [1] http://lists.freebsd.org/pipermail/freebsd-fs/2005-October/001382.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org font size=1 div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in' /div This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying
