[RC1] Login not possible
Robert Watson
rwatson at freebsd.org
Sat Dec 13 16:06:51 PST 2003
On Sat, 13 Dec 2003, Klaus-J. Wolf wrote:
> Excuse me, but the limit of a maximum of 16 group memberships per user
> has not been known to me. It would be a good idea to document it
> somewhere.
>
> I know a number of persons who will run into problems because their idea
> of proper system architecture requires certain persons to be a member of
> a higher amount of user groups. Until now, it might not have worked, but
> the day it finally crashes and nobody can log in anymore, will not make
> them happy.
>
> There should be an option, somehow.
All UNIX systems I know of have relatively low upper bounds on the number
of groups permitted per process. This is generally well-documented in
programmer documentation, but sometimes less well documented in user
documentation. You can test the value on POSIX-esque systems using
getconf(1):
paprika:~> getconf NGROUPS_MAX
16
You can also test it programatically using sysconf(3). I believe POSIX
mandates a minimum of 16 groups, and also fairly common. Here are some
values extraced by various people for me:
Operating System NGROUPS_MAX
FreeBSD 4.9 16
FreeBSD 5.2 16
Linux 2.4.2 32
IRIX64 6.5 16
SunOS 5.7 16
SunOS 5.8 16
OSF1 V4.0 32
OSF1 V5.1 32
HP-UX B.11.22 20
HP-UX B.11.23 20
AIX 4.3 32
AIX 5.x 64
It could we be we should think about bumping _SC_NGROUPS_MAX to 32,
although this might have substantial ABI impacts we'd have to look into
carefully. You can also add optional groups, joined using newgrp(1), but
the lack of a shadow password database for that is fairly limiting (and
it's far from user friendly compared to just being a member of more
groups).
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org Senior Research Scientist, McAfee Research
>
> Robert Watson wrote:
>
> >FWIW, I think that failing here is the right thing to do (since otherwise
> >the kernel silently changes the access control rights of processes), but
> >that the failure error is a bit obscure. That said, the setusercontext()
> >API isn't really set up to provide more detailed error information, so
> >we'll need to expand the API. I wonder if it would make sense to modify
> >the pw/etc commands to generate warnings if they discover a user in too
> >many groups...
> >
> >
> >
>
>
More information about the freebsd-current
mailing list