Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development (http://www.linux-archive.org/fedora-development/)
-   -   private group administration (http://www.linux-archive.org/fedora-development/178086-private-group-administration.html)

Robert Locke 10-17-2008 02:11 PM

private group administration
 
On Fri, 2008-10-17 at 14:00 +0200, Lutz Lange wrote:

> Hi all,
>
> i was thinking about user creation and group administration. Every user
> gets his own private group when he is created. And the motivation for
> that is to avoid users sharing files with all other users to per default
> right?
>
> But what if the user wants to change his files with a specific user or
> two? An easy though not well known way to do that would be to push these
> users into the private group. For this to work the user has to be
> Administrator of his private group.

No, you are mixing collaboration with equivalence. Putting someone in
your private group is more like making them you (based on current
implementation). "ALL" my files are rw- by my private group.

>
> ( eg. i'm tux with group tux
> - root has to make me administrator of my private group :
> # gpasswd -A tux tux
>
> now i can get paul in to my private group
> tux@somewhere ~> gpasswd -a paul tux
>
> or i could set/change my group passwort
> tux@somewhere ~> gpasswd tux
>
> change rights on /home/tux
> tux@somewhere ~> chmod g+rx .
>
> don't forget to check all the other dirs and files for group access
> tux@somewhere ~> ls -la .
>
> you might want to remove group and other bits
> tux@somewhere ~> chmod g=,o= * .*
>
> explicitly open a project dir in /home/tux
> tux@somewhere ~> mkdir project
> tux@somewhere ~> chmod g+rwx project
>
> Writing this i realize that this will only make sense if i use the right
> umask. So lets set it to something more secure, since i might not want
> to change all my files with paul.
>
> tux@somewhere ~> vi .bashrc
> umask 077
>
> All right it might not be in my best interest to share something in my
> home dir, or if i do i have to be very careful about the permissions
> there...

So now the private group is not private and is more of a collaborative
group which is no longer "just working" and requiring the user to make a
bunch of caveats.... Changing the umask now breaks the way we "teach"
to do collaboration which takes advantage of the umask 0002 and uses
SGID to cause the collaborative group to be inherited from the directory
rather than the "primary/private" group of the process. A slippery
slope....

Just use ACLs. They are turned on by default by anaconda on our ext3
filesystems now through the filesystem superblock.

>
> But i still thinks a user should be in control of his private group.
> )

Well, I don't have a good argument as to why a user should not be able
to administer their own private group, but still believe your "case
study" is better served by ACLs....

>
> But he is not. This has to be set explicitly by the entity that creates
> the user. I wonder what the reasoning is/was behind that.
>
> Why is a user not made administrator of his private group per default?
>
> Cheers
> Lutz

--Rob

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Les Mikesell 10-17-2008 05:05 PM

private group administration
 
Lutz Lange wrote:


i was thinking about user creation and group administration. Every user
gets his own private group when he is created. And the motivation for
that is to avoid users sharing files with all other users to per default
right?


Not exactly. Having your own private group assigned from the start
makes it possible to use a default umask that gives group access to your
files without actually giving anyone else access yet. That means
when/if you do want to let someone else have access, you don't have to
go back and change the permissions on all your existing files and
directories.




tux@somewhere ~> vi .bashrc
umask 077


Don't forget to compliment the bits. The default umask 002 gives group rwx.


All right it might not be in my best interest to share something in my
home dir, or if i do i have to be very careful about the permissions
there...


No, the point of the private group is to permit access to everything
that is yours. If you don't want that, make a new group with the
appropriate set of users added and use that group ownership instead of
your own.



But i still thinks a user should be in control of his private group.
)

But he is not. This has to be set explicitly by the entity that creates
the user. I wonder what the reasoning is/was behind that.

Why is a user not made administrator of his private group per default?


Think of common multiuser scenarios - like an office or school.
Individuals are typically not in charge of their collaborative groups -
that will be assigned by someone else.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Matthew Woehlke 10-18-2008 12:12 AM

private group administration
 
Les Mikesell wrote:

Lutz Lange wrote:


i was thinking about user creation and group administration. Every user
gets his own private group when he is created. And the motivation for
that is to avoid users sharing files with all other users to per default
right?


Not exactly. Having your own private group assigned from the start
makes it possible to use a default umask that gives group access to your
files without actually giving anyone else access yet. That means
when/if you do want to let someone else have access, you don't have to
go back and change the permissions on all your existing files and
directories.


...which means as soon as you save something to a setgid directory, you
just gave the world (or at least, some larger group) write permission to
your files. Personally I always considered umask 002 to be Evil. Better
to make it hard to intentionally grant others write for your files than
to make it easy to accidentally give write permission that you didn't
want to give.


If 'chmod g+w file;chgrp foo file' is too much work then there should be
a command that can do both.


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
When on POSIX, do as POSIX mandates.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Colin Walters" 10-18-2008 12:21 AM

private group administration
 
On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
>
> If 'chmod g+w file;chgrp foo file' is too much work then there should be a
> command that can do both.

Groups are broken. Use access control lists: "man setfacl"

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Les Mikesell 10-18-2008 02:17 AM

private group administration
 
Colin Walters wrote:

On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:

If 'chmod g+w file;chgrp foo file' is too much work then there should be a
command that can do both.


Groups are broken. Use access control lists: "man setfacl"


Groups have never been broken. Access control lists let you set up a
mishmash of exceptions that nobody can understand or recreate and not
all tools understand them when making copies or backups or working
across different platforms.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Till Maas 10-18-2008 06:45 AM

private group administration
 
On Sat October 18 2008, Colin Walters wrote:
> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
>
> <mw_triad@users.sourceforge.net> wrote:
> > If 'chmod g+w file;chgrp foo file' is too much work then there should be
> > a command that can do both.
>
> Groups are broken. Use access control lists: "man setfacl"

ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that
everything within a certain directory is owned by everyone of a group, i.e.
they all can do whatever they want with these files and directories without
using sudo. The problem is, that the group permissions of a file constrain
the permissions for all group acl permissions.

Regards,
Till


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Callum Lerwick" 10-18-2008 08:09 AM

private group administration
 
This is among the oldest of the old FAQs:

http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Colin Walters" 10-18-2008 02:40 PM

private group administration
 
2008/10/18 Till Maas <opensource@till.name>:
> On Sat October 18 2008, Colin Walters wrote:
>> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
>>
>> <mw_triad@users.sourceforge.net> wrote:
>> > If 'chmod g+w file;chgrp foo file' is too much work then there should be
>> > a command that can do both.
>>
>> Groups are broken. Use access control lists: "man setfacl"
>
> ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that
> everything within a certain directory is owned by everyone of a group,

The point is with ACLs you don't need the files to have a specific
ownership (user/group) as long as they have the right ACLs for access.
A good way to do this is to avoid groups entirely and just add the
users you want individually.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

seth vidal 10-18-2008 02:53 PM

private group administration
 
On Sat, 2008-10-18 at 10:40 -0400, Colin Walters wrote:
> 2008/10/18 Till Maas <opensource@till.name>:
> > On Sat October 18 2008, Colin Walters wrote:
> >> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
> >>
> >> <mw_triad@users.sourceforge.net> wrote:
> >> > If 'chmod g+w file;chgrp foo file' is too much work then there should be
> >> > a command that can do both.
> >>
> >> Groups are broken. Use access control lists: "man setfacl"
> >
> > ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that
> > everything within a certain directory is owned by everyone of a group,
>
> The point is with ACLs you don't need the files to have a specific
> ownership (user/group) as long as they have the right ACLs for access.
> A good way to do this is to avoid groups entirely and just add the
> users you want individually.

If there are enough people working on a project this does not scale.

-sv


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Chuck Anderson 10-18-2008 04:25 PM

private group administration
 
On Sat, Oct 18, 2008 at 10:53:05AM -0400, seth vidal wrote:
> On Sat, 2008-10-18 at 10:40 -0400, Colin Walters wrote:
> > 2008/10/18 Till Maas <opensource@till.name>:
> > > On Sat October 18 2008, Colin Walters wrote:
> > >> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
> > >>
> > >> <mw_triad@users.sourceforge.net> wrote:
> > >> > If 'chmod g+w file;chgrp foo file' is too much work then there should be
> > >> > a command that can do both.
> > >>
> > >> Groups are broken. Use access control lists: "man setfacl"
> > >
> > > ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that
> > > everything within a certain directory is owned by everyone of a group,
> >
> > The point is with ACLs you don't need the files to have a specific
> > ownership (user/group) as long as they have the right ACLs for access.
> > A good way to do this is to avoid groups entirely and just add the
> > users you want individually.
>
> If there are enough people working on a project this does not scale.

Right, with groups you can have files inherit the group from the
directory they are in. Is there any inheritance with ACLs?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


All times are GMT. The time now is 11:54 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.