Date: Fri, 12 Mar 2010 18:33:26 +1030 From: Rob <listone@deathbeforedecaf.net> To: Gary Gatten <Ggatten@waddell.com> Cc: freebsd-questions@freebsd.org Subject: Re: ACLs, umask and shared directories Message-ID: <D57598FC-5E8D-469A-8AEF-CD4F864E8826@deathbeforedecaf.net> In-Reply-To: <29288_1268317482_4B98FD2A_29288_166_1_70C0964126D66F458E688618E1CD008A08CCF744@WADPEXV0.waddell.com> References: <29288_1268317482_4B98FD2A_29288_166_1_70C0964126D66F458E688618E1CD008A08CCF744@WADPEXV0.waddell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > 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? >=20 >=20 >=20 > ----- Original Message ----- > From: Rob <listone@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 >=20 > Hi Gary, >=20 > Directory group inheritance is the default in FreeBSD - see open(2): >=20 > When a new file is created it is given the group of the > directory which contains it. >=20 > In SysV, this behaviour is controlled by the setgid bit. >=20 > 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. >=20 > I just can't see a tidy solution. >=20 > Thanks > Rob. >=20 > On 09/03/2010, at 10:34 AM, Gary Gatten wrote: >=20 > > > > 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 =3D 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: 'listone@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; 'listone@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: 'listone@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-questions@freebsd.org > > <owner-freebsd-questions@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-unsubscribe@freebsd.org" > > > > > > > > > > > > <font size=3D"1"> > > <div style=3D'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> > > >=20 >=20 > "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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D57598FC-5E8D-469A-8AEF-CD4F864E8826>