Solar Designer wrote:
>
[PAM_PRELIM_CHECK/PAM_UPDATE and asking current password]
> > This is how things implemented in current pam_unix. This also seemed
> > strange to me, and so I asked about it.
>
> Did you get an answer from Andrew? This is really not specific to
> just pam_unix.
Unfortunately, not (yet?). Ok, will do it right.
[]
[salt generation, gettimeofday, etc, /dev/urandom]
#if HAVE_COMPLETE_LIBC_SUPPORT_FOR_THIS_ALL
use all the good new interfaces, $prefix, $count, crypt_gensalt() etc.
Ok, pretty nice case.
#elif HAVE_SMART_CRYPT_THAT_UNDERSTANDS_MD5
#if HAVE_DEV_URANDOM <<<<-- not all systems have this :(
read 6 bytes from /dev/urandom etc
#else /* !HAVE_DEV_URANDOM */
/* wow, little trouble. Should use gettimeofday etc or own "random device" (rnd? ;) */
#endif /* HAVE_DEV_URANDOM */
use crypt("$1$" + salt, passwd)
#else /* not HAVE_SMART_CRYPT_THAT_UNDERSTANDS_MD5 nor HAVE_COMPLETE_LIBC_SUPPORT_FOR_THIS_ALL */
/* only plain crypt */
/* ok, maybe I can omit md5 in this case */
salt should also be choosen well, but not with the same care as for md5
#endif
Good. At least I know well now what should be done here
(not so ugly with all those #if's but anyway).
-------
Ok. I hope that almost all now clean in my mind.
I need a big look to all of this as a whole, some thinking
and a bit of very careful coding. :)
I'll take a look to all the code that you mentioned also, to get
ever cleaner/complete picture.
I plan to finish "first public" ("previev"?) release to this weekend
that has at least support for current glibc's crypt with md5 salts,
other variants will come shortly after. The same codebase will be
used for other password changing stuff like pam_passwd_files (just a
cut-off from pam_unix), pam_passwd_nisplus and maybe others.
Unfortunately (as usual), I can only work on this at evenings/nights,
so why things are so slow now. But I see a light at the end of
tunnel. ;-)
Regards,
Michael.
