[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: kern.ngroups question
From:       Hartmut Brandt <hartmut.brandt () dlr ! de>
Date:       2007-07-19 20:51:18
Message-ID: 469FCEC6.8090600 () dlr ! de
[Download RAW message or body]

Reuben A. Popp wrote:
> On Wednesday 18 July 2007 21:19, Michael Vince wrote:
>> Julian Elischer wrote:
>>> Reuben A. Popp wrote:
>>>> Hello all,
>>>>
>>>> Can someone explain to me the rationale behind having ngroups_max set
>>>> to 16 by default?
>>> NFS only supports this much by default (from memory).
>>>
>>> Samba (in the guise of Jeremy Allison)
>>> has asked us to follow Linux's lead and support an arbitrary number of
>>> Groups
>>> but it hasn't happened yet, Partly due to the question of "what to do
>>> about NFS" and partly just due to ENOTIME.
>> I think at the very least that there should be some more obvious
>> warnings about this potentially serious limitation in either release
>> notes of FreeBSD and or Samba.
>>
>> I just had to deal with this limitation and it was quite annoying to say
>> the least, it appears Samba is somewhat deliberately designed to give
>> you a hard time when you run into this limit, because as soon as you add
>> a user to more than 16 groups it declares the group file unreadable and
>> as a security measure shuts down all shares and authentication which
>> wrecks a network which relies on Samba.
>>
>> Also as far as I know Solaris and Linux has long gone past this limitation.
>>
>> Mike
> 
> Running into a problem nearly identical to Mike's is what caused me to start 
> researching ngroups in the first place.  Granted, in our Samba 
> implementation, there isn't really anyone who hits the limitation (short of 
> the admin), but the problem is still a definite show stopper.
> 
> I imagine this will become even more of an issue once Samba 4.x is completed 
> and sees deployment.  Maybe this weekend I can write a small blurb for the 
> handbook
> 
> I guess the next question I have would be about the limit in NFS.  I did a 
> little sleuthing and found out that the actual culprit is not necessarily 
> NFS, but the underlying RPC calls.  IF I'm reading this correctly (excuse me 
> if I'm wrong.. I'm just now getting my feet wet with c/c++), the limit is set 
> in the auth_unix structure (taken from RFC 1057):
> 
> struct auth_unix {
>      unsigned int stamp;
>      string machinename<255>;
>      unsigned int uid;
>      unsigned int gid;
>      unsigned int gids<16>;
> };
> 
> If the value for gids were to be changed, that obviously would mean that the 
> RPC implementation would be out of whack with the standard.  How then are the 
> other *nixes getting around this issue?
> 
> Thanks again
> Reuben A. Popp
> 
> Just a note:  As I said above, I'm still just now getting my feet wet in any 
> kind of programming (other than shell scripting).  If I make an incorrect 
> assumption or a pretty stupid mistake, all I ask is to be kind :)
> 

I'm somewhat getting tired to repeat that you may raise ngroups if you 
want. I fixed a couple of bugs with this, and I run ngroups=64 for 
almost 2 years (with authenticating against an AD with users in a lot of 
groups). For NFS the code just passed the first 16 groups, so you might 
not get access to files that you should get access to based on group 
memberships. A problem might be when you NFS export a filesystem with 
deny ACLs. Then a user might get access to a file he should not. I would 
think of this as a good reason not to make ngroups > 16 the default.

harti
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]