Date: Wed, 18 Dec 1996 20:00:12 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: wosch@cs.tu-berlin.de (Wolfram Schneider) Cc: current@freebsd.org Subject: Re: group(5) limits Message-ID: <199612190100.UAA06326@skynet.ctr.columbia.edu> In-Reply-To: <199612182336.AAA00506@campa.panke.de> from "Wolfram Schneider" at Dec 19, 96 00:36:45 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Wolfram Schneider had to walk into mine and say: > Bill Paul writes: > >While removing the static membership limit of 200 is probably okay, NIS v2 > >is permanently saddled with a record limit of 1024 bytes. The yp_mkdb(8) > >utility enforces this. The limit is part of the yp.x protocol, consequently > >to change it would break compatibility with all other NIS implementations. > >This means these changes would be fine for local /etc/group files, but > >you'd still be stuck with a 1024 byte line limit if you choose to use > NIS. > > I can reduce the limit from 256K to 1k. Technically you can leave it at 256K, it's just that if you go to turn your /etc/group file into an NIS map the yp_mkdb(8) program and you have lines longer that 1024 bytes, it'll complain that the lines are too long and skip them. Whether or not this constitutes a reason for keeping the limit in getgrent(3) at 1024 bytes is debatable. It may be enough to put a warning in the man page that while the getgrent(3) code can handle line sizes up to 256K, they won't work with NIS. > But didn't we already break > NIS with increasing user name length from 8 characters to 16 > characters? No. NIS itself doesn't care about the size of the individual fields in the passwd or master.passwd records. In NIS, keys and data are essentially opaque buffers that can be at most 1024 bytes in size (in practice, the data in the buffers is usually limited to ASCII characters but it can really be anything). It's up to getpwent(3) or getpwent(3) to parse the data in the buffers and handle field overflows accordingly. In our case, the buffer returned from NIS is handled more or less in place: the username field is not copied to statically sized buffer that might overflow. The 1024 byte limitation in NIS v2 stems from Sun's decision to use ndbm as the database backend for their NIS implementation. The ndbm code is also limited to 1024 byte keys and data. When Sun wrote the NIS v2 protocol definition, they explicitly limited the size of keys and data to 1024 bytes to match the ndbm limit. Consequently, even though we use Berkeley DB (hash method) which can handle keys and data up to 4GB in size (in theory :), our NIS implementation still has to abide by the limit in the protocol definition if it is to be compliant with all the other NIS implementation currently in use. In other words: yes this sucks; blame Sun. :) NIS+ works entirely differently (as you might expect). It uses a new relational database backend (libnisdb) which does not have the same limitations as ndbm. Data is stored in tables that can have up to 64 columns (any one of which may be marked searchable) and and the columns themselves can be arbitrarily large (according to the protocol specification anyway -- the server or the database backend may choose to limit the size to keep resource usage from getting out of hand). The database backend also allows duplicate entries (where 'duplicate' means more than one entry that matches the same exact search conditions), though I haven't experimented with the server to see if it allows it as well. If it does, then you could have two entries for 'group=foo,uid=1234' with totally different group membership lists. Whether or not the client library can merge them back into a single grp struct I don't know. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612190100.UAA06326>