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, 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_users 0 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 of this email > > and its attachments, if any, is strictly prohibited. If you have > > received this email in error, please immediately notify the sender by > > return email and delete this email from your system." > > </font> > > > > > "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 of this email and its attachments, if > any, is strictly prohibited. If you have received this email in error, please > immediately notify the sender by return email and delete this email from your > system." _______________________________________________ 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"
