[lkml]   [2000]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.2.* kernels w/ glibc-2.1.* allowing ngroups_max to be > 128?
"List User" <>:
> 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

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

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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:58    [W:0.036 / U:2.492 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site