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

Re: pam_crypt module will change the world

Stuff for modular crypt api...
>  - a function to compare a cleartext password to a given hash string
>    without the caller having to know what the type of the hash is

>  - a function to generate a hash from a given cleartext password using a
>    configurable default crypt type

>  - a function to generate a hash from a given cleartext password and a
>    given crypt type name
I didn't think about this.  This is easy though.

>  - a function to enumerate crypt types available
This either.. hehe.  Slightly harder.  Probably easiest to just return a two
dimensional array of char *.  I can't think of a simpler method. Can you?

>  - a free() function (if the API allocates its own result storage)
pfft. what's a few bytes? :).  Yeah this part is a little bit more tricky to
do "correctly." It would [might] be better to leave it to the user though to
make things simple for both the programmer using the api and me.

> Of course, such an API would have to be multi-thread safe.
Of course. Everything has to be mutli-thread safe.  Not sure if this can be
said for current pam_crypt code. I haven't done a thread safety audit
because it's still alpha.

So in conclusiong, the pam_crypt code does [will do] these things. I have
done some serious thinking about where I'd like to take this, and I've
decided to fork the current path of pam_crypt.  I will have a seperate
library that implements the stuff you just talked about.  I will then
implement the idea I was talking about just recently with a modular way of
storing/retrieving password hashes.

I actually decided on the fork before I read your email.  I didn't even
think about the third/forth ideas you presented. They could be very useful.
Pam_unix and friends can then do the work of dealing with nis/nss/whatever.
I'll continue development on the stand-alone module for the time being (with
seperation of the stand-alone module from the crypt() api).  I will probably
have this done by tonight (if I don't get too depressed about having nothing
to do on a friday night :).  We'll see what happens.

There are some small issues not related to the code that need to be worked
out though:

Naming suggestions? Since a modular crypt api isn't really going to be pam
specific I can't exactly call it pam_crypt. libmca sounds stupid.

Distribution suggestions? How do we make this available to pam modules?  I
guess it "might" be ok to distribute it seperately and then have the modules
check for it (there will have to be a header file, for example), but if
every pam module supports this api (in like a year or so) then maybe it
needs to be a part of pam.  I really don't know how to handle this.  Even if
this turns out to be a wonderful api/library, nobody will bother to use it
if it's a pain to get it working with pam.  I believe this is why not very
many people use solar designer's glibc patch.  This is also probably one of
the subconcious reasons I went with a stand-alone module.

I'd really like to thank Solar Designer and Nicolas Williams. Pam_crypt
would be heading in a very differant direction if it wasn't for you guys.
Steve Langasek too, you've provided some good ideas I might use with the
stand alone library.

- Adam Slattery

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