Messages in this thread | | | From | "List User" <> | Subject | Re: 2.2.* kernels w/ glibc-2.1.* allowing ngroups_max to be > 128? | Date | Mon, 7 Aug 2000 21:21:59 -0500 |
| |
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" <pollard@tomcat.admin.navo.hpc.mil> To: <matthew@wil.cx>; "Jesse Pollard" <pollard@tomcat.admin.navo.hpc.mil> Cc: <lists@chaven.com>; <linux-kernel@vger.rutgers.edu> Sent: Monday, August 07, 2000 14:46 Subject: Re: 2.2.* kernels w/ glibc-2.1.* allowing ngroups_max to be > 128?
> Matthew Wilcox <matthew@wil.cx>: > > 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: pollard@navo.hpc.mil > > Any opinions expressed are solely my own. >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |