[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 2nd Qs: proposed description of new pam_unix

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]


use all the good new interfaces, $prefix, $count, crypt_gensalt() etc.
Ok, pretty nice case.


#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)


/* 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


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.  ;-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []