removal of NGROUPS_MAX dependancy from base
ttw+bsd at cobbled.net
Mon Feb 23 00:11:06 PST 2009
On 22.02-16:28, Brooks Davis wrote:
> On Sun, Feb 22, 2009 at 11:07:19AM +0000, ttw+bsd at cobbled.net wrote:
> > On 21.02-22:49, Julian Elischer wrote:
> > [ ... ]
> > > >this patch should remove the dependancy on the definition of
> > > >NGROUPS_MAX as a static constant and implement it as a writable
> > > >sysconf variable of the same. it should also make the necessary
> > > >changes to the codebase to support those.
> > [ ... ]
> > > What do you do about NFS?
> > > I seem to remember that NFWS had a maximum number of groups supported..
> > NFS will be supported by mapping 16 groups into the auth_unix structure
> > dynamically. my intention is to try and make this transparent by
> > allocating moving the 'most used' groups into that mapping as user
> > processes check them, however, this is very conceptual at the moment
> > and needs more thought as well as validation from others with more
> > experience.
> I think this behavior will probably need to be configurable by the
> administrator because some sites are probably using groups to supply
> negative permissions. It's quite reasionable to argue that's a bad
> idea, but we need to take some care since people do occationally use
> that "feature".
agree. i'm hoping to make the rpc group allocations dynamic and thus,
mostly transparent, but would suggest the only consistent way
administrators to set permissions (when NFS is required) is to restrict
NGROUP_MAX to 16 or less. i intend this to be the default, changed
my current primary concern is with software that defines it static
arrays with a length of NGROUPS_MAX and then forgets to sanitize
'ngroups' count against that maximum but no idea how to catch those
except too say that is 'broken'.
More information about the freebsd-hackers