Date: Tue, 3 Dec 1996 09:36:28 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: babkin@hq.icb.chel.su (Serge A. Babkin) Cc: hackers@freebsd.org, stesin@gu.net, narvi@haldjas.folklore.se Subject: Re: Does anybody need it ? Message-ID: <199612031436.JAA19505@skynet.ctr.columbia.edu> In-Reply-To: <199612031207.RAA01265@hq.icb.chel.su> from "Serge A. Babkin" at Dec 3, 96 05:07:42 pm
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, Serge A. Babkin had to walk into mine and say: > > > I agree wholeheartly with you here; probably default of up to 2048 > > > users/group and 16k bytes would be Ok? (Hope it won't be too big > > > a waste of resources). > > > > > > > Hmm... I thought you could have several lines with one group? > > > > Like in: > > > > users:*:30000:user1,user2,user3,user4,user5,user6,....,user20 > > users:*:30000:user21,user22,user23,user24,...user40 > > > > etc. > > > > At least the getgr...() manpage says that its behavior is undefined > if there are several lines for the same group. This might work only halfway. When trying to lookup a group in order to learn all its members, it will fail: only the first line will match, and the second one will be ignored. When looking to see if a particular user is a member of a group, it might work since the search is for a particular username rather than a group name. Netgroups may be cascaded in order to overcome the 1024 line size limit. Normal groups may not. Netgroups are also useful for limiting login access to machines. > And would it work together with NIS ? No. The backend of ypserv is a hash database, and unlike /etc/pwd.db and /etc/spwd.db, it doesn't have the original data encoded three times (i.e. for getpwnam(), getpwuid() and getpwent()). It has each entry encoded just once; having two entries in a hash database with the same key doesn't work, so having two groups with the same name is impossible. The yp_mkdb command watches for entries with duplicate keys and discards the dupe when it catches it (generating a warning message in the process). And before someone asks, no you can's change NIS to allow longer records. There's a 1024 byte limit on keys and data inherent in the RPC protocol definition for NIS v2 (which I think stems from the ndbm library only allowing 1024 bytes for keys and data): if you change this and rebuild the system, you will break compatibility with all other NIS implementations on the planet. Now, libnisdb, the backend of rpc.nisd for NIS+, allows duplicate database entries and doesn't have a 1024 byte limit on record sizes. (The libnisdb I wrote as part of the FreeBSD NIS+ project also allows duplicates.) However I'm not sure that rpc.nisd itself allows duplicate records; it may enforce a restriction independent of what the library permits. -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?199612031436.JAA19505>