Re: about common group & user ID space (PR kern/14584)
From: Sergey Babkin (babkin@bellatlantic.net)
Date: 03/20/01
- Next message: Robert Watson: "Re: about common group & user ID space (PR kern/14584)"
- Previous message: Sergey Babkin: "Re: about common group & user ID space (PR kern/14584)"
- In reply to: Terry Lambert: "Re: about common group & user ID space (PR kern/14584)"
- Next in thread: Brett Glass: "Re: about common group & user ID space (PR kern/14584)"
- Reply: Brett Glass: "Re: about common group & user ID space (PR kern/14584)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 19 Mar 2001 20:15:11 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Terry Lambert <tlambert@primenet.com>
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
- Next message: Robert Watson: "Re: about common group & user ID space (PR kern/14584)"
- Previous message: Sergey Babkin: "Re: about common group & user ID space (PR kern/14584)"
- In reply to: Terry Lambert: "Re: about common group & user ID space (PR kern/14584)"
- Next in thread: Brett Glass: "Re: about common group & user ID space (PR kern/14584)"
- Reply: Brett Glass: "Re: about common group & user ID space (PR kern/14584)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
