xdm-shadow (was Re: 1.3 installation report.)
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
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: