Re: 2.2.* kernels w/ glibc-2.1.* allowing ngroups_max to be > 128?

[List User]

Our situation here is that we have several groups based on clients.  Each
client is a group and has several users in that group.  Likewise we have an
internal support group for each client which also consists of several users.
In addition to this we have certain processes (PGP, and others) that need to
cross both groups to move data & encrypt it.  No one in any group should
have ownership authority for the directories.  Only user associated to the
'system' tasks (like PGP) should have access to all groups.  Internal users
should have access to their own group files as well as files to only the
clients that they support.

The problem rises when some clients have sub-vendors that need to be part of
that client's group but are not allowed to
see any other sub-vendor's data.  But all internal and the client can see
that data.  It's a convoluted system to really describe in a
post but groups are the best way I can think of handling all the iterations.
However the limits of groups is what is killing me now.

Since most of the access to this system in non-interactive (handled by FTP,
or daemon processes) in chrooted environments
most user-based solutions (sudu, et al) get sticky or
non-usable/maintainable.

The post that Frank came up with patching the kernel & glibc seems to be the
best route.  I'm trying to aquire a PC system
to test it on this week.  If all goes well it will be in production shorly
after.

Steve
----- Original Message -----
From: "Jesse Pollard" <[e-mail]>
To: <[e-mail]>; "Jesse Pollard" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Monday, August 07, 2000 14:46
Subject: Re: 2.2.* kernels w/ glibc-2.1.* allowing ngroups_max to be > 128?

> Matthew Wilcox <[e-mail]>:
> > On Mon, Aug 07, 2000 at 08:38:55AM -0500, Jesse Pollard wrote:
> > > The problem is compatability. It is not possible to change the limit
if NFS
> > > is being used. 256 groups would just about use up half the UDP packet
just
> > > for the group list.
> >
> > that's bogus; RPC/XDR allows for counted arrays.  Colour sun stupid for
> > limiting it to 16.
>
> True about RPC/XDR, but NFS isn't XDR.
>
> > > If you think you need 256 groups per user, then I think you should
partition
> > > your users differently. It sounds like an improper use of groups. This
almost
> > > sounds like one group per user.
> >
> > that's not an improper use of groups.
>
> It becomes improper WHEN it is decided that one user should be in 256
groups.
> I wasn't meaning improper as in "should never be done" but more that it is
> likely being used for something that it wasn't designed to do.
>
> Now it IS possible to use newgrp to switch groups, and an extension (not
> THAT big) can be used to allow a user to switch to any (authorized) group.
> It just is not really reasonable to try to be a member of ALL groups ALL
the
> time.
>
> > --
> > Revolutions do not require corporate support.
> >
>
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: [e-mail]
>
> Any opinions expressed are solely my own.
>