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

Re: GDBM/DB password file support



Derrick J. Brashear wrote:
> >  libpwdb was intented to help us with user / group lookups. But I agree 
> >  that a hesiod module should be nice. I don't have the docs/idea how to do 
> >  it, though.
> 
> Aren't you getting into the realm of what nsswitch does? Wouldn't it be better
> to just let nsswitch do it? Or do I misunderstand libpwdb?
> 

Yes. As Marek pointed out there is going to be some overlap. We regret this.
However, the principal difference is that libpwdb makes the source of the
database information available to the application and can also be specified
explicitly by the application.. [Whereas the nisswitch approach maps all
getpw.. requests to a specific database that is out of the control (and even
unknown) to the application]

This feature is critical if one is to ensure that PAM modules can have
control over the users they are authenticating, it is also important for
applications that maintain the content of specific databases. It is our hope
that these applications will find libpwd a convenient interface to their own
databases.. Something that is likely to help with issues of locking etc.

As for a release date for .53 it is a question of what you want. My working
libpam has only changed a little: pam_get_user now sets the PAM_USER item
(as the Sun docs say it should) which means the type of its char **user
argument has become const **user) and the Makefile structure has been
extensively rewritten to (hopefully) make porting to other platforms easier.
There is also no reference to advisory locking in libpam itself.

All of the work (that Cristian and I are doing currently) is going into
libpwdb. We are trying to get it to the point that we can provide a libpwdb
based pam_unix module that will be "all singing all dancing". I would estimate
2-3 weeks (but it has been like this for the last month! :)

After the next (one or two) releases, I would like to start releasing
libpam{,-misc} separately from the modules... This will make individual
module developers more responsible for their code and free up my time for me
to make a start on implementing a pluggable gss library.... [<gratuitous
self promotion>If anyone out there would like to offer me some financial
independence from physics.. This will get done a lot quicker!</gratuitous
self promotion> ;]

For a flavor of things coming in future releases, The people at Sun are
preparing to enhance the PAM spec. Hopefully this will include a number of
suggestions from this list(!) and also the long promised environment
handling.. There is also talk of replacing the "troublesome" use_mapped_pass
convention with a new module type: "mapping" .. I'm happy to take care of
the libpam socket for this, but someone outside the US should probably host
a collection of such modules.... But that is for the future and the
timescale for it (from Sun) is not clear.

Best wishes

Andrew



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