Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!lll-winken.llnl.gov!sol.ctr.columbia.edu!startide.ctr.columbia.edu!wpaul From: wpaul@ctr.columbia.edu (Bill Paul) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Bug in NIS? (2.0.5) Date: 19 Oct 1995 00:54:14 GMT Organization: Columbia University Center for Telecommunications Research Lines: 72 Distribution: world Message-ID: <4647jn$mt5@sol.ctr.columbia.edu> References: <SCOTTE.95Oct18100727@odie.center.uscs.com> NNTP-Posting-Host: startide.ctr.columbia.edu X-Newsreader: TIN [version 1.2 PL2] Daring to challenge the will of the almighty Leviam00se, L. Scott Emmons (scotte@center.uscs.com) had the courage to say: : Has anyone noticed that FreeBSD 2.0.5 does not like NIS group maps : with groups having many members? Looks like there is an internal : buffer-size limit. Well, the way FreeBSD's getgrent code works, NIS data is basically just passed into the normal local group handling routines. Unfortunately, there are bugs in the 2.0.5 code that can cause to screw up if you put your magic +::: entry somewhere in the middle of /etc/groups rather than the end. However, there is an internal limit in NIS. The protocol definition for NIS v2 says that a single NIS record may not be longer than 1024 bytes in size (YPMAXRECORD). This, coincidentally, is also the maximum size for a key. (Check /usr/include/rpcsvc/yp.x and you'll see all the defined limits.) I think part of the reason this limit exists has to do with the fact that Sun originally used NDBM as the database system used to store map information, and NDBM has internal limits that prevent you from going to crazy with key/data pair sizes (as well as the overall number of possible key/data pairs that can be contained in a single database file). FreeBSD's NIS tools use Berkeley DB, which doesn't have the same limitations as NDBM -- keys and data can be of arbitrary size and type -- but it sticks to the protocol limitations to stay compatible with everybody else. If you look at getgrent.c, you'll see that it also defines the maximum size of an /etc/group line as 1024 bytes (MAXLINESIZE) and that it discards lines that are over this size. The base getgrent code also keeps an array of 200 pointers which point to the member names. This means that there's a limit of 200 members per group. The algorithm is basically to read a line, then chop it up into pieces by replacing the separators (colons or commas) with NULs, and assemble the grp structure using pointers that point at the individual pieces. This saves you from having to copy, say, each member name into seperate buffers. With NIS, the only difference is that the buffer that gets chopped up is retrieved from the NIS group maps instead of a local file. The 1024 byte limit hurts netgroups too, but with netgroups you can cheat by dividing up your netgroups into smaller netgroups, then making the smaller netgroups all be members of one top level netgroup (sort of like a tree). Unfortunately, you can't do that with normal user groups. However, there are other bugs in 2.0.5 that can cause you grief. These bugs might cause trouble with group entries that are much smaller than 1024 bytes. In particular, if you have a badly formatted entry (say, with not enough colons, or spaces instead of commas, or some other such thing), then there's a chance the code might SEGV. : If you have an entry that's too long the system becomes unusable - you : can't login or anything. It would be nice if you could figure out how long is too long (and then tell us!! :). If the offending group entry is 1024 bytes long, then you've hit the limit of the protocol. If it's markedly less than that, it's likely a bug, and I'll need more details to troubleshoot it. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= License error: The license for this .sig file has expired. You must obtain a new license key before any more witty phrases will appear in this space. =============================================================================