[557] in linux-security and linux-alert archive
Re: Password checking - JFH the way forward ?
daemon@ATHENA.MIT.EDU (Marek Michalkiewicz)
Wed Jan 10 16:41:40 1996
From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
To: ian@chiark.chu.cam.ac.uk (Ian Jackson)
Date: Wed, 10 Jan 1996 22:03:42 +0100 (MET)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <m0ta16s-0002aEC@chiark.chu.cam.ac.uk> from "Ian Jackson" at Jan 10, 96 02:02:00 pm
Note: please send replies to me and Ian, not to the list, to save the
moderators some work. I can summarize any good feedback, too.
Since I am the current maintainer of the Linux port of the JFH's shadow
password suite, perhaps I should say something in my defense here.
I'm not going to rehash the old advocacy arguments either.
First of all, I don't know why our exchange was unsatisfactory for Ian.
We disagree on some points, but I think there is nothing wrong with it,
and no one of us is always absolutely right...
Some facts about the JFH's shadow suite:
- the "API" it implements, while not ideal, is compatible with the SVR4
standard; this means that most reasonably current portable sources should
already support that, and in most cases they will need only some Makefile
editing; if necessary, I can help with this - just contact me.
- shadow passwords are supported by the current ELF libc, and you don't
need any other libraries to write shadow-aware applications; it is also
easy to do it in such a way that the same binaries work with both shadow
and non-shadow passwords.
- many people use the shadow suite, and are familiar with it, it is the
defacto Linux standard (it was not supported by distributions in the past
for copyright reasons, but that can change now), people have scripts that
depend on it, some BBS programs depend on useradd etc.
- the shadow suite, while still beta (it has problems too), has many new
features not supported by the standard util-linux programs used by most
distributions.
Now, I can see it isn't fun to recompile all password-checking programs,
and the Ian's proposal should make it possible to support shadow passwords
transparently, but I can see one sometimes quite serious problem with it:
We store our encrypted passwords in a completely different way, and can't
easily share them with other systems. It is possible to share them with
Linux systems using that scheme, but there is no easy way to modify libc
on non-Linux systems to implement the same scheme.
Another thing that is debatable - should we try to make everything ideal,
or maybe stick to existing standards well known for a few years now?
Maybe I am a bit conservative, but I would prefer the latter. I doubt
the SVR4 shadow password API will change again in the near future, and
if we want to support other authentication schemes (for example S/Key),
the pwdauth() API is probably not general enough.
If we want to modify libc and be sure that all old binaries still work,
it would be necessary to implement (and maintain) the changes in the old
no longer maintained a.out libc as well. If we do it only for ELF, then
there are not many old binaries...
I think both schemes (the Ian's transparent shadow password support, and
the JFH's SVR4-compatible shadow passwords) can probably be implemented
at the same time, and should be optional. Maybe this is the solution we
all can agree on?
Again, discussion is welcome, please send replies both to me and Ian (not
to the list). I can post a summary if there are enough interesting replies.
Regards,
Marek
