Date: Mon, 19 Mar 2001 20:15:11 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Terry Lambert <tlambert@primenet.com> Cc: Brett Glass <brett@lariat.org>, security@FreeBSD.ORG, Wes Peters <wes@softweyr.com>, Robert Watson <rwatson@FreeBSD.ORG>, fs@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: about common group & user ID space (PR kern/14584) Message-ID: <3AB6AF1F.9452E231@bellatlantic.net> References: <200103182339.QAA18696@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > > At the same time, it'd be nice to eliminate the arbitrary limitations These things are not really related to the common ID space. I definitely would not like to do them in the same patch, just to keep things separate. > > on (a) the number of groups of which a user can be a member and (b) the For this there is some macro (can't remember the name) which can be defined in the kernel config file as an option with a higher value. Setting it higher means higher system overhead but since the memory size has increased significantly over the last few years, I think that a higher default value makes sense. > > number of members in a group. Both of these limitations often bite > > administrators who, for example, want most users of a system to be > > members of a particular group or want to implement group-based access > > control schemes with a moderate degree of granularity. Classes won't > > cut it for this purpose, alas, because they're not built into file > > system security. > > I think that you will run into the limitations inherent in the > quota record storage format and NFSv2 UID/GID, well before you > face that limit. > > There is really no limit on the number of members permitted in a > group, I believe. If you are talking about line length, I'd say I think there is such a limit. Or at least it was in the 2.0.5 days. I'm not sure about the line length limit. I remember that there was such a limit in SVR4.2, so if a group line grew past some size, getgrent() and friends went crazy. > you should consider getting rid of "pico" and using a real editor. The common workaround it to split a group record into multiple lines in /etc/group, like: staff:*:20:root staff:*:20:babkin Keep no more than about ~50 users per line. This may break things like adduser but it's not a big loss. The important things, such as setting process permissions on login, work fine. > I think there are patches floating around to allow repeats of > group lines in order to set up larger lists of members, in any > case (they may already be integrated into FreeBSD; they aren't in > BSDI, from looking at the BSDI system I have access to). No patches are really required. If you discount the secondary stuff like useradd/adduser, repeated lines just work out of the box on all the Unix systems where I tried: FreeBSD, Linux, HP-UX, UnixWare, SCO OpenServer, ICL DRS/NX (old SVR4.2). -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB6AF1F.9452E231>