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

Re: PAM and shadow

Wichert Akkerman wrote:
> > > I'm still curious why pam_start() doesn't allow a PAM module to
> > > initialize itself, since that would solve this problem cleanly without
> > > needing an externaly program, and might solve future problems as well.
> >
> > Could you elaborate?

> You could do something like this:
> - someone calls pam_start
> - pam_start figures out which modules to use and loads them
> - pam_start calls an initialize function for each module
> - initialize for pam_shadow does fopen("/etc/shadow")
> - main program drops root priviledge
> - main program attempts to verify a user and calls pam_authenticate
> - pam_shadow can still access /etc/shadow since it has an open
>   filehandle, and uses fgetpwent to get the right entry.

This is an interesting idea. I guess, in the specific case of
/etc/shadow, the reason why this sort of thing has not been implemented
is that it means that applications that were to use PAM to talk to
modules like pam_unix (et al) would _have_ to be setuid-root.  In the
case of things like xlock, most people agree this would be a bad thing.

What you want regarding 'initialization' is already there (to some
extent) dlopen (which is how libpam loads the modules) supports the
_init and _fini functions. In addition, PAM supports the module function
calls pam_[gs]et_data(), which can be used to store things like database
connection handles etc. .  In order to use these latter calls, you need
to have a pamh, but that's available the first time pam_authenticate is



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