Date: Mon, 2 Jan 1995 04:41:09 -0500 (EST) From: Wankle Rotary Engine <wpaul@skynet.ctr.columbia.edu> To: freebsd-hackers@freebsd.org Subject: Re: NIS stuff update Message-ID: <199501020941.EAA01587@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
They say this Thomas Gellekum person was kidding when he wrote: > Wankle Rotary Engine wrote: > > > - Teach yppasswdd how to handle FreeBSD's password database system. > > I have begun to write a yppasswdd some time ago, when I thought I > had the time to finish it. Turned out I was wrong. Anyway, I used > some of the routines from passwd and vipw; building the database is > handled by makedbm (or yp_mkdb as you called it). Converting yppasswdd turned out to be very simple once I took a look in /usr/src/usr.bin/passwd. This particular version fork()s off a child process to run a program to rebuild the NIS maps. I'm using a script for that for now. > > I don't suppose anybody knows how to export /etc/master.passwd without > > the whole world being able to see it. > > You should not need /etc/master.password. YP should have its own > database in /var/yp. The /etc/master.password should only regulate > access to the server and not contain the user entries for the > machines in the current domain. > > This was one thing I didn't like about the Linux YP implementation > when I looked it a while ago. > > tg > Actually, you do need to export /etc/master.passwd -- or at least a file with the same format. The secure password database doesn't just contain encrypted passwords: it contains password aging information and other assorted crap (some of which may or may not be implemented yet) which FreeBSD client machines would need to know about. The existing YP client functions in libc assume that the server they'll be talking to uses standard /etc/passwd-style maps, which means they have to be altered slightly in order for the additional information to be extracted from the maps. This is something I'll be looking at tomorrow, since I've done more than enough hacking today. :) But forgetting the format difference for the moment, there's still the matter of keeping the encrypted passwords away from prying eyes. The whole point of /etc/master.passwd and /etc/spwd.db is to have a secure password database that only the superuser can access so that you won't be vulnerable to 'Crack' attacks. What I want to do is allow FreeBSD machines to be configured as NIS clients while still only allowing the superuser to access encrypted passwords. Since sending my last message (yesterday :), I've discovered a half-assed way to do it: the NIS server can check the TCP ports from which requests originate. Requests from processes running as root will originate from privileged ports; requests from normal users will not. I just finished hacking ypserv such that it will return YP_YPERR if it receives a request to access master.passwd.* that does not come from a privileged port. This is far from perfect, but it's a) better than nothing, and b) reasonably effective when used in conjunction with address authentication (tcp wrappers). This raises another question: the ypserv code as hooks in it for libwrap.a from the tcp wrapper package. Would it be possible to include the tcp wrapper code with the next version of FreeBSD so that ypserv can be secure right out of the box, or should it be shipped insecure with a notice telling people how to add tcp wrapper support later? Anyway, here's yet another update. Stuff I've done: - Hammered on the db code in ypserv so that it properly emulates the behavior of the old GNU dbm routines. NOTE: the dbopen() man page is slightly incorrect!! The following code does not work: db = dbopen(dbname, O_RDWR|O_EXCL, PERM_SECURE, DB_HASH, &openinfo); (db->db_seq)(db, &key, &data, R_CURSOR); <-- returns EINVAL The R_CURSOR flag is *NOT* supported with using db->seq with the DB_HASH access method, but the man page leads one to believe it otherwise. (I would have *never* figured this out without the source to libc. :) This lead to some really silly workaround code. Bah. - Hacked ypserv to support ypxfr. - Hacked ypserv to refuse requests to access the master.passwd.* maps that do not originate from privileged ports. - Hacked ypserv to properly background itself like a good little daemon should. Added syslog/fprintf functions: syslog when running as daemon, print to stderr when running in debug more (with -debug flag). - Converted yppasswdd to use the pw_util.c and pw_copy.c routines already in the FreeBSD source tree (/usr/src/usr.bin/passwd and /usr/src/usr.sbin/vipw). - Successfully tested yppasswdd with yppasswd and ypserv. - Cleaned up ypxfr and converted it to use the db functions. - Successfully tested ypxfr with a SunOS NIS server. - Converted yppush to use db functions. - Moved everybody into appropriate places in the source tree and created BSD-style Makefiles. Here's the heirarchy I have so far: /usr/bin/yppasswd /usr/libexec/ypserv /usr/libexec/yppasswdd /usr/libexec/pwupdate (script used by yppasswdd) /usr/libexec/yppush /usr/libexec/ypxfr /usr/sbin/yp_mkdb /var/yp/Makefile /var/yp/mknetid (a shell script) Stuff I haven't yet done: - Hack libc/gen YP routines (_pw_breakout_yp() and probably others) to support master.passwd.* maps in addition to existing /etc/passwd-style maps. - Clean up a few compiler warnings in yppush. - Properly test yppush. (How the hell do I do that with only one FreeBSD machine?!) - Test yppasswdd a bit more. (Still not sure I got the conversion exactly right, even though it seems to work.) - Hack yppasswdd to allow the use of an alternate raw master.passwd file. (Thanks for reminding me. :) - Clean up the Makefiles. - Dump it all on Jordan's head. Wait, I'm forgetting something... There's still something left for me to do... Oh. Oh yeah: sleep. G'night. -Bill -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Bill Paul System Manager wpaul@ctr.columbia.edu Center for Telecommunications Research (212) 854-6020 Columbia University, New York City ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Møøse Illuminati: ignore it and be confused, or join it and be confusing! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501020941.EAA01587>