Recursive groups anyone?

Recursive groups anyone?

[Paul Furness]

Hi.

I just spent a good hour scouring the Internet for this, and came up
with a blank. Maybe someone on here has an answer...

I'm looking to do something that is conceptually very simple: I want to
create recursive entries in linux groups so that I can make groups
members of other groups. For example:

group1:x:1000:paul,matt,dave
group2:x:1001:karen,sally,tara
biggroup:x:1002:bossman,lampyman,group1,group2

I'm pretty sure that you can't do this normally, but _someone_ must have
wanted to do this before. Does anyone know of any way of making this
happen? If so, are there any good security reasons not to do it?

Presumably, this is not a function of the file system (be it ext3,
reiserfs, xfs or whatever) but rather the security modules in the
kernel.

What actually looks up group membership when you try and read a file?
Does anyone have any thoughts on the ease (or not)  of hacking that part
of the kernel?

Similar code already exists in sendmail and similar for mail groups.
Hmm, I wonder how portable that might be?


Another problem (which is a separate thing, I guess) is that if I change
the group membership of someone, they have to log out and back in again
to get their new groups showing. Does anyone know how to make this
dynamic?

I suppose another approach might be to write a front-end script that
manipulates the group file (it's shared using NIS so I only have to do
it one place) and allows me to easily manage group memberships and make
people members of many, many groups (typically people are already in 5
or so groups.) I _could_ create a group for each group of files and then
add people to all the groups they need access to, but that's bloody
complicated to keep track of! Groups in groups would be _so_ much
easier. Also, this still doesn't prevent the logging out / in thing.



All the file systems are used by people over NFS, so there might also be
a way of doing this at the NFS level, but I think that may be slower and
I'd rather it worked on local file systems as well. This would, however,
probably be dynamic so I could change memberships on the fly....


Any ideas anyone?

Paul.


-- 
Paul Furness

Systems Manager

2+2=5 for extremely large values of 2.

Re: Recursive groups anyone?

[Glynn Clements]

Paul Furness wrote:

> I just spent a good hour scouring the Internet for this, and came up
> with a blank. Maybe someone on here has an answer...
> 
> I'm looking to do something that is conceptually very simple: I want to
> create recursive entries in linux groups so that I can make groups
> members of other groups. For example:
> 
> group1:x:1000:paul,matt,dave
> group2:x:1001:karen,sally,tara
> biggroup:x:1002:bossman,lampyman,group1,group2
> 
> I'm pretty sure that you can't do this normally, but _someone_ must have
> wanted to do this before. Does anyone know of any way of making this
> happen?

Write a script to generate /etc/group from a "source" file.

> If so, are there any good security reasons not to do it?

No.

> Presumably, this is not a function of the file system (be it ext3,
> reiserfs, xfs or whatever) but rather the security modules in the
> kernel.
> 
> What actually looks up group membership when you try and read a file?

Every process has a foreground group id plus a number of supplementary
group ids. Programs which provide user logins (e.g. "login", "xdm"
etc) set the foreground group id from /etc/passwd, and the
supplementary group ids from /etc/group. Child processes inherit these
values from their parent. Filesystem accesses are checked using the
attributes of the calling process.

> Does anyone have any thoughts on the ease (or not)  of hacking that part
> of the kernel?

You can't realistically implement your policy at the kernel level.

> Similar code already exists in sendmail and similar for mail groups.

I don't think so. I suspect that you're misunderstanding some aspect
of mail delivery.

> Hmm, I wonder how portable that might be?
> 
> 
> Another problem (which is a separate thing, I guess) is that if I change
> the group membership of someone, they have to log out and back in again
> to get their new groups showing. Does anyone know how to make this
> dynamic?

A process' attributes can't be changed externally (from another
process). They can be changed by the process itself, but changing
user/group ids requires root privileges in the general case.

For shell sessions, a user could run "login" manually to obtain a
shell with the updated group ids.

> I suppose another approach might be to write a front-end script that
> manipulates the group file (it's shared using NIS so I only have to do
> it one place) and allows me to easily manage group memberships and make
> people members of many, many groups (typically people are already in 5
> or so groups.) I _could_ create a group for each group of files and then
> add people to all the groups they need access to, but that's bloody
> complicated to keep track of! Groups in groups would be _so_ much
> easier. Also, this still doesn't prevent the logging out / in thing.
> 
> 
> 
> All the file systems are used by people over NFS, so there might also be
> a way of doing this at the NFS level, but I think that may be slower and
> I'd rather it worked on local file systems as well. This would, however,
> probably be dynamic so I could change memberships on the fly....
> 
> 
> Any ideas anyone?

What you seem to be trying to acheive can't be done. If it could, it
would probably have adverse implications for security.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: Recursive groups anyone?

[Paul Furness]

On Fri, 2002-09-13 at 15:53, Glynn Clements wrote:
> 
> > 
> > What actually looks up group membership when you try and read a file?
> 
> Every process has a foreground group id plus a number of supplementary
> group ids. Programs which provide user logins (e.g. "login", "xdm"
> etc) set the foreground group id from /etc/passwd, and the
> supplementary group ids from /etc/group. Child processes inherit these
> values from their parent. Filesystem accesses are checked using the
> attributes of the calling process.
> 
> You can't realistically implement your policy at the kernel level.

Hmm, now I get it. Thanks.

> 
> > Similar code already exists in sendmail and similar for mail groups.
> 
> I don't think so. I suspect that you're misunderstanding some aspect
> of mail delivery.

I was thinking of the aliases file expansion, but since I didn't
understand how the filesystem access worked, I didn't realise that it
didn't matter anyhow. :)

> 
> What you seem to be trying to acheive can't be done. If it could, it
> would probably have adverse implications for security.
 
Well, the 'instant update' of group memberships is only a minor
inconvenience - again, that came from me not really understanding how
file permissions were checked.

Groups within groups would have made the permissions much easier to
manage, but I can simply write a more complex admin tool to take care of
that and generate /etc/group after having expanded groups locally.

Thanks.

Oh, erm, what is the maximum group membership allowed? Is it alterable?
(I seem to remember it was limited to 16 on Solaris, but was
configurable. I also seem to remember that something else - possibly NFS
or NIS - broke if you set the max groups too high.)


Thanks again.

P.







 
-- 
Paul Furness

Systems Manager

2+2=5 for extremely large values of 2.

Re: Recursive groups anyone?

[Glynn Clements]

Paul Furness wrote:

> Oh, erm, what is the maximum group membership allowed? Is it alterable?
> (I seem to remember it was limited to 16 on Solaris, but was
> configurable. I also seem to remember that something else - possibly NFS
> or NIS - broke if you set the max groups too high.)

The value can be obtained from the constant NGROUPS_MAX, defined
(indirectly) in limits.h. It can't generally be altered (typically, a
process table entry includes a fixed-size array of the supplementary
GIDs). On Linux 2.4, the limit is 32.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: Recursive groups anyone?

[Jamie Harris]

> Presumably, this is not a function of the file system (be it ext3,
> reiserfs, xfs or
whatever) but rather the security modules in the
> kernel.
>
> What actually looks up
group membership when you try and read a file?
> Does anyone have any thoughts on the ease (or
not)  of hacking that
> part of the kernel?

Group membership would be looked up by the C
library so you might want to look in the area of nss (name service switch)
libraries.
>
Another problem (which is a separate thing, I guess) is that if I
> change the group
membership of someone, they have to log out and back
> in again to get their new groups
showing. Does anyone know how to make
> this dynamic?

Are you changing their primary
group of adding them to additional groups?  How are you checking their
membership?  Usinggetent etc or something else?

You might want to look into storing your group information
in another way rather than tradition groups files under NIS.  LDAP might
provide you with whatyou're looking for as I imagine you would just query the directory for  group
membership.

cheers, good luck

Jamie...

-- 
**  This message was transmitted on
100% recycled electrons **

Re: Recursive groups anyone?

[Paul Furness]

Thanks.

Hmm, I'll have to do with scripts by the look of things.

On Fri, 2002-09-13 at 17:10, Jamie Harris wrote:
> 
> Are you changing their primary
> group of adding them to additional groups?  How are you checking their
> membership?  Usinggetent etc or something else?
> 
It was mainly for secondary group changes. I was looking at it very
simply: I wanted to be able to give someone rights to a group, and them
be able to immediately access the file (eg using cat). 

But I can't do that, since (as GC explained) the group memberships are
attached to the process - so you can't change them externally. I guess I
_could_ probably write a script to update the running process (provided
it's a shell) but it's only a minor inconvenience - people are usually
ok about logging out when they have asked for group membership to be
changes.


> You might want to look into storing your group information
> in another way rather than tradition groups files under NIS.  LDAP might
> provide you with whatyou're looking for as I imagine you would just query the directory for  group
> membership.

That _might_ be easier to manage, possibly, but I don't now think it'll
make any difference to the log out/in thing. Like I say, that's less
important.

Thanks.

P.


-- 
Paul Furness

Systems Manager

2+2=5 for extremely large values of 2.

Re: Recursive groups anyone?

[Glynn Clements]

Paul Furness wrote:

> But I can't do that, since (as GC explained) the group memberships are
> attached to the process - so you can't change them externally. I guess I
> _could_ probably write a script to update the running process (provided
> it's a shell)

The fact that the supplementary GIDs are tied to the process is only
part of the problem; the other part is that changing them requires
root privilege.

-- 
Glynn Clements <glynn.clements@virgin.net>