Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 May 2005 14:21:19 -0600
From:      Chris Warren <chris@dawgiestyle.com>
To:        cs <cs-fbsd@ctzen.com>
Cc:        FreeBSD <freebsd-questions@freebsd.org>
Subject:   Re: Is this possible ? inherit group permissions
Message-ID:  <1116879679.11570.0.camel@localhost.localdomain>
In-Reply-To: <4292399E.30107@ctzen.com>
References:  <42900CC6.4090701@ctzen.com> <44wtpq13lu.fsf@be-well.ilk.org> <20050523093759.M47072@mail.goinet.com> <44u0ktzufo.fsf@be-well.ilk.org> <4292399E.30107@ctzen.com>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
Just a guess, but would the sticky bit help here?

Chris

On Mon, 2005-23-05 at 16:14 -0400, cs wrote:
> Lowell Gilbert wrote:
> > Tony Shadwick <tshadwick@goinet.com> writes:
> > 
> > 
> >>On Mon, 23 May 2005, Lowell Gilbert wrote:
> >>
> >>
> >>>cs <cs-fbsd@ctzen.com> writes:
> >>>
> >>>
> >>>>For a directory, e.g. foo/, if I chmod 775 foo/, is it possible for
> >>>>newly created files and directories under foo/ to automagically
> >>>>inherit the group permissions of foo ?
> >>>>
> >>>>e.g.
> >>>>touch foo/test would be rw-rw-r--
> >>>>mkdir foo/sub would be rwxrwxr-x
> >>>>
> >>>>I am looking for a non umask solution.
> >>>>
> >>>>I seem to remember in debian, I was able to make the group permissions
> >>>>of the parent directory special for this magic to occur.
> >>>>
> >>>>I wonder if there is something similar in FBSD.
> >>>
> >>>If you set the suid bit, both owner *and* group will be set.
> > 
> > 
> >>I'll have to remember that one.  So if /home is a filesystem unto
> >>itself, if you set the suid bit on /home, all further creation beneath
> >>it will inherit the permissions you set above?
> > 
> > 
> > Only *directly* underneath it.  Obviously you wouldn't want to do that
> > for /home, but I find it quite useful on shared project directories
> > and the like.
> 
> If you are talking about inheriting group identity, that is not what I 
> am asking for.  I believe this is automagic under fbsd, e.g.
> 
> mkdir foo
> chgrp somegroup foo
> touch foo/foofile
> mkdir foo/foodir
> 
> foo/foofile and foo/foodir will have gid somegroup (without any suid or 
> sgid).
> 
> What I am more interested in is inherting group permissions.
> 
> For example, I have a directory /var/www/foosite, which allows several 
> different users to maintain it.
> 
> One way to do it is to use a common account for all the users to 
> maintain foosite.
> 
> But it is "too loose" in accountability.
> 
> Going full version control (cvs/subversion) is not really desired for me 
> because it's not a "mission critical" thing.
> 
> What I would like to do is create a group (say foogroup), assign all 
> maintainers to the group, chgrp foogroup /var/www/foosite, and chmod g+w 
> /var/www/foosite.
> 
> Here is the "fun" part.
> 
> User umask is 022 (which I would like to maintain).
> 
> touch foosite/foofile
> mkdir foosite/foodir
> 
> would render those new file/dir NOT group writable.
> 
> umask 002 would make them group writable BUT it is a "global" setting 
> and would affect other parts of the file system as well (e.g. user's home).
> 
> Plus not all users are savvy enough to do umask 002 / umask 022 whenever 
> necessary.
> 
> I am looking for an "elegant" solution which I doubt I will find.
> 
> After some thoughs, this is my "compromized" solution.
> 
> The users will maintain foosite via ftp (within a VPN), and I use vsftpd 
> and set the ftp umask to 002.
> 
> -cs
> _______________________________________________
> 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"

[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCkjs+5oLdYlMF6RsRAugKAKCJrwdvImFkkGssACVDZBBw9JQ2HgCeJfva
koxfEiznp5bzYS9L9965mP8=
=uXtZ
-----END PGP SIGNATURE-----
help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1116879679.11570.0.camel>