Re: Recursive groups anyone?

[Paul Furness <paul.furness@vil.ite.mee.com>]

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.