Re: [RC1] Login not possible

From: Robert Watson <rwatson_at_freebsd.org>
Date: Sat, 13 Dec 2003 19:06:33 -0500 (EST)
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... 
> >
> >  
> >
> 
> 
Received on Sat Dec 13 2003 - 15:06:51 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:34 UTC