Hi, Mark Eichin: > 2) the xdm shadow support doesn't fall back in any sane way, > and it's more than just dropping a check -- a bunch of code needs > rearrangement. (If you run xdm-shadow on a non-shadow system, you *lose*...)
Well, I just did that with xbase-3.2-6: # mv /usr/X11R6/bin/xdm-shadow /usr/X11R6/bin/xdm I can switch back and forth between shadow and non-shadow passwords, and can login via xdm just fine. Nothing bad happened, my machine hasn't exploded yet, etc. :-) There was indeed a problem with XFree86-3.1.2 (xdm-shadow didn't work with non-shadow passwords), but not with 3.2 and higher. With 3.2 and 3.2A, the only thing that remains to be fixed is the Imakefile that still generates two separate xdm binaries. I reported this to the XFree86 upstream maintainers, and got a reply from David Dawes: "We've dealt with this finally, and it will be fixed in 3.3." So, I would appreciate if it could be fixed in the next Debian 1.3 xbase release. Just move that single binary... > I've never understood why the debian shadow code was so primitive. Not just Debian, and not just Linux - getspnam() is also used on several other systems, Solaris being one of them. Like many other UN*X things, it is not perfect, maybe it is even primitive, but it works and is standard. Most reasonably current, portable sources, already know about getspnam(). > Any reason why the classic "getpw* give you a password field if you've > got root" implementation isn't used? I can think of a few reasons > (avoiding coredumps in programs not actually needing passwords) but Another reason is that in the past some setuid root programs (chfn, chsh) used to get the passwd entry using getpwnam(), modify it, and write it back to /etc/passwd. Congratulations, you just unshadowed your system... Sure, they can (and should) be fixed, but I prefer to play it safe. Besides, there is more information in /etc/shadow than just the encrypted passwords, and that information (password aging) would be lost. The people at AT&T who added getspnam() to SVR4 a few years back could probably give a better answer to this question than I did. Of course this is a matter of personal opinion, but I for one consider getspnam() to be the "classic" shadow password implementation. (Some systems actually do the getpw* thing, but I think it is a little unsafe.) > they're kind of weak [and could be handled better by simply providing > a shadow_need_passwords() call to enable the feature...] Non-standard - there are already so many different shadow password implementations... Regards, Marek -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
