From owner-freebsd-hackers Thu Jul 20 09:00:04 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id JAA12350 for hackers-outgoing; Thu, 20 Jul 1995 09:00:04 -0700 Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id IAA12337 for ; Thu, 20 Jul 1995 08:59:58 -0700 Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.11/8.6.9) id LAA03486; Thu, 20 Jul 1995 11:57:59 -0400 From: A boy and his worm gear Message-Id: <199507201557.LAA03486@skynet.ctr.columbia.edu> Subject: Re: getpwent() YP/NIS bugu To: terry@cs.weber.edu (Terry Lambert) Date: Thu, 20 Jul 1995 11:57:56 -0400 (EDT) Cc: iidpwr@lightlink.satcom.net, jim@reptiles.org, hackers@freebsd.org In-Reply-To: <9507191753.AA28401@cs.weber.edu> from "Terry Lambert" at Jul 19, 95 11:53:15 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 7283 Sender: hackers-owner@freebsd.org Precedence: bulk Of all the gin joints in all the world, Terry Lambert had to walk into mine and say: > > Yes, I have the same problem too. I use +:*:0:0:::::: instead of +::::::::: Uh... wait a minute. Back up. The main place where people get tripped up is the UIG/GID fields: in SunOS (and those systems that license the Sun NIS code), the UID and GID fields are never remapped, but the password, gecos, home directory and shell fields are (the man pages say so). This means that sticking a '*' in the password field of the wildcard entry will remap all users' passwords to '*' no matter what platform you're using, so you shouldn't be using that. (There is a '*' in the magic NIS entries that pwd_mkdb creates in /etc/passwd, but those don't mean anything: all the entries in /etc/passwd in FreeBSD have '*' in their password fields.) As for the remapping of UIDs and GIDs itself, FreeBSD has always done that, and I decided to leave it that way once I started banging on the NIS code since it didn't seem like a terribly bad idea to allow it. (I never could figure out why Sun excluded the UID and GID fields like that.) It's very easy to change the code so that it mirrors the SunOS behavior, but just because Sun doesn't do it that way doesn't mean FreeBSD's approach is incorrect. > > The real problem of this I cannot find this in any documentation that comes > > with FreeBSD. Documentation this certainly would help promote FreeBSD. Yes, I know. The man pages never did say much about the magic NIS overrides. Now that I've finished my latest round of hacking, I finally have some time to concentrate on fixing that. > > Little thing can makes a big different. I cannot tell you in words how > > frustrated I was while I cannot make NIS works right. I have UnixWare, AIX > > running NIS in my office. Well I have SunOS, Solaris, IRIX, HP-UX, FreeBSD and Sony NEWS OS running all running NIS in mine. And they all work fine. > The "real problem" (tm) is that once it sees the "+" it shouldn't care > about the rest of it. > > The place this is broken is in the pwmkdb, which should assume the rest > to the end of the line *for you* when you put in a naked '+:' > (not just a naked '+', followed by anything, since netgroups are > identified that way). > Terry Lambert > terry@cs.weber.edu > --- > Any opinions in this posting are my own and not those of my present > or previous employers. I'm sorry Terry, but I can't parse this to save my life. The only difference between FreeBSD's magic NIS override handling and SunOS's handling (that I can tell from looking at the Sun man pages and observing SunOS's behavior) is that FreeBSD remaps the UID and GID fields and SunOS doesn't. (There's another difference which is that FreeBSD will also remap the extra fields in master.passwd-style password files, but since there is no direct analogue to master.passwd in SunOS, it's difficult to say whether this behavior is correct or not.) The wildcard entry (+::0:0::: in SunOS or +::::::::: in FreeBSD) should _not_ require any special handling in pwd_mkdb. It's just another magic NIS entry like all the others, except, being a wildcard, it matches against everybody. You don't believe me? Go to any NIS client machine and change +::0:0::: to +:*:0:0::: and see what happens; all users NIS users will have '*' as their password. Now go to FreeBSD and do the same thing; again, all passwords will be remapped to '*'. The question is how to set things up to please everybody. I for one feel that FreeBSD's NIS override mechanism is very nice and that you _should_ be able to override all the fields in a user's password entry (if you don't want a particular field overridden, then don't fill it in!). Others may not agree. The difficulty is that the library code isn't psychic so it can't automatically figure out which way you want it to work. The only way I can see to resolve this is to create an /etc/nis.conf file that lets you configure FreeBSD's NIS behavior just like /etc/host.conf lets you configure the resolver. In fact, this would let me solve a couple of nagging problems. For example, some of you may have noticed that FreeBSD only uses the netgroup map whereas other systems use netgroup, netgroup.byuser and netgroup.byhost. The reason it does this is because FreeBSD (well, 4.4BSD-Lite in general, really) has a local /etc/netgroup file, which no other OS has. Again, I like the idea of being able to use either a local file or NIS for reading netgroups; with the current system, you can even have locally defined netgroups that include references to NIS netgroups. But there's a price to pay: netgroup lookups done through just the netgroup map can be very slow if your netgroup database is large, since you need may need to search pretty far down into the database before you find all the members of a particular group. In particular, this hurts innetgr() a lot. The netgroup.byuser and netgroup.byhost are meant to solve this problem since they contain all the netgroup 'dependencies' already worked out for you, but you can't use these maps _and_ maintain the 'locally defined netgroup that includes references to NIS netgroups' feature at the same time. Well, I mean, you could do it, but you'd have to go through a lot of work to resolve everything correctly, and the time you'd waste would negate the advantage of using the special maps in the first place. The only way out of this is to offer the user a choice and let them configure the system to their taste. You could have things like this: # If we're being served by a FreeBSD ypserv, set this to 'yes' so # we can use the 'shadowed' master.passwd.byname and master.passwd.byuid # maps. If being served by a standard 'SunOS-style' ypserv, set it to # 'no.' # nis_use_master_passwd_maps=yes # Setting this to 'yes' allows FreeBSD to use its own local /etc/netgroup # file in conjunction with the NIS netgroup map. Setting it to 'no' causes # local /etc/netgroup files to be ignored; netgroups will only be read # from NIS, and the netgroup.byuser and netgroup.byhost maps will be # used to make netgroup lookups faster. # nis_freebsd_style_netgroups=yes # Set this to 'yes' if you want to have FreeBSD remap all the fields # in users' NIS password entries, including UIDs, GIDs and (if using the # master.passwd maps) expiration, aging and class data. Set it to 'no' # if you want 'SunOS-style' password remapping where the UIDs and GIDs # are not modified. # nis_remap_all_passwd_fields=yes Those are the three main issues I can think of for now. If people think this is a good idea, now's the time to speak up so that I can start working on it and get all the man pages in order. Suggestions for other options would be welcome too. -Bill -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Møøse Illuminati: ignore it and be confused, or join it and be confusing! ~~~~~~ "Welcome to All Things BSDish! If it's not BSDish, it's crap!" ~~~~~~~