Messages in this thread | | | Date | Mon, 7 Aug 2000 08:38:55 -0500 (CDT) | From | Jesse Pollard <> | Subject | Re: 2.2.* kernels w/ glibc-2.1.* allowing ngroups_max to be > 128? |
| |
"List User" <lists@chaven.com>: > I just found out today that SUN/Solaris cannot handle more than 32 > groups/user. > I have a need to have certain users in more than 128 groups (preferred 256 > or more). > > I am hoping that someone here could answer these questions (and maybe get a > Linux > system into a SUN shop. ;) )
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.
> 1) Can Linux 2.2.* / glibc 2.1.* handle > 128 groups per user? > 1a) What files need to be modified to do this? > 1b) Does glibc-2.1.* take this information dynamically from the kernel > header files?
There are two other problems with this -- 1. the buffer size required to read the groups from the group file 2. Some limits on the size of a record in NIS (many systems have a 1024 byte limit).
1b. No - there is no location in the kernel for this. It is a constant. In some cases it is possible for the getgroups library to determine how many a user is in, then it is up to the application to allocate the memory for that many.
> 2) What are the maximum sizes of the /etc/groups file. > 2a) Maximum line size (1024?) > 2b) Maximum number of groups > 2c) Maximum number of bytes for the file itself
The file maximum is not a problem (it uses a linear search to locate it). The problem is the number of groups in a single record. Each group is represented as a sinle line. The line limit depends on the utilities used to read it -- vi can only go up to about 250 characters, login has a different limit, and NIS still another.
You may run into a performance problem before the file size even enters the equation. Since the file is a linear scan for each entry, and "ls" shows user/group names, the bigger the password/group file gets, the longer it will take to list it. This also applies to ps, though there may be some caching done on user names for active processes. I ran into this with only a 1000 users, and switched to using NIS to recover the response rate since NIS uses a keyed file to locate names.
> 3) What are the maximum sizes of the /etc/passwd & /etc/shadow files? > 3a) Maximum number of users > 3b) maximum size of these files?
Same answer. Size of file is not the problem, length of record is. Currently the maximum number of password entries is 65535. This limit can be exceeded only by the complete implementation of large UID support. The standard limit is a 16bit unsigned value. When full support of large UID is available I believe the limit is what will fit in a 24bit integer (or a 32bit unsigned, depending on approach used...). Note : -1 and -2 (65535 and 65534) are reserved to identify the "nobody" users, though they should have entries already.
I haven't yet seen a complete implementation.
> If anyone can answer this or point me to the answers I'd greatly appreciate > it. > My back is up against a wall with Solaris/SUN and need to get a solution > that > will work in place ASAP. Oh, I know that NFS will break with > 16 groups > but that is not important (this server will not be exporting NFS > filesystems).
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.
BTW, if this is some managers idea of how to read everybodys files, then there are simpler ways to do it - you may be forced to write a "sudo" wrapper for newgrp that allows that manager to set any group as the active group for his process.
This can be extended by having a setuid program (yeah - horrors, but the only way right now), that can use the current uid as a key to lookup a list of groups the user is allowed to switch to. This bypasses the /etc/group file (other than for looking up the gid) and still allows some control over what groups the user can switch to. Effectively it is a replacement for newgrp that is specifically built to handle your situation. You might even look into newgrp source and see if you can adapt it for this use (even to porting the result to Solaris).
------------------------------------------------------------------------- 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/
| |