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

Re: PAM concepts (was: pam_{unix,pwdb}: crypt/md5 necessary?)

On Thu, 3 Aug 2000, Michael Tokarev wrote:

> > I think that modularity, in this case, means writing modules which are wholly
> > independent of one another.  PAM modules should interoperate nicely, but no
> > PAM module should depend on other modules to do its job.

> We have many useful modules.  If we also have one (or more) good (simple) password-asking
> module, this will not be an issue.  Recall that problems with RedHat paths
> to cracklib dicts exists in _unix and _pwdb also.  If you won't use cracklib, --
> viola, another simple module can be used for this.  This can also be implemented
> by having simple config file for "pam_askpass" and pam_cracklib with system-wide
> defaults so there will be no need to edit each file in /etc/pam.d.  Again, with
> pam_stack it is not an issue.  I think that _reasonable_ dependences between
> modules are ok.  If one module requires pam_cracklib, it is bad.  But if one
> requires _any_ "asking" module of your taste, it is ok.  Well, we at least
> should place some module for each stack of login service for example.  Think
> as about having just one more "stack" -- "password_ask".  Password stack is
> useless for login if there is no modules in auth stack!
> Yes, each module can ask of it's own.  I think that this is just a waste of
> efforts (and having use_authtok in /etc/pam.d/* after pam_unix is ugly),
> and cause more incompatibilities (prompts are not standartized etc) as you
> see in pam_cracklib itself.

My point is, by changing all of our existing pam modules to not prompt for new
passwords, we lose modularity and simplicity from an administrative viewpoint.
Right now, I can create a very simple PAM config file for any service:

auth      required  pam_unix.so
account   required  pam_unix.so
session   required  pam_unix.so
password  required  pam_unix.so

... and this will work for most services.  If you take password prompting
support out of pam_unix.so, you have to put it somewhere else -- either in
libpam (in which case you've effectively changed the PAM spec), or in a
separate module.  If you put it in a separate module, you have to list the
module in the configuration, which adds more complexity.  Is code reuse in
the modules a good enough reason to add this complexity?

Remember that PAM was created to make *administration* easier.

> Consider for example:
>   samba -- charset conversation/classification.  There are iconv and locale
>     already.  Both implemented well (almost?) in glibc.  Maybe implemented
>     reasonably well on BSD.  Others?  -- samba does not use any of this,
>     have own implementation, and now samba team have troubles implementing
>     unicode conversations.  Already implemented elsewhere...

There are a lot of things you have to implement yourself if you want your code
to be portable.  We're going to run into the same issue soon in Linux-PAM,
because a number of people think that Linux-PAM /should/ be more portable.

> ------------------
> And some issues to concretic statements about code.

> > The calls are necessary because glibc's NIS+ nsswitch module won't let a
> > program see the password field for any user other than the one which matches
> > the program's euid.  Because we don't know what permissions the program will
> ...

> Ok, I just don't understand _what_ it does. :)  Why it does it is not a
> question. But it is not a real question here.

It changes the euid in a way that's reversible under Linux.

> Efficiency also concerned here, too.  What I did in my (re)implementation
> is to define one routine (pam_unix_init()) that accepts a flags and fills in
> (retrieves) all passwd/shadow stuff if needed, storing it in one structure
> and setting flags if say shadow entry unavailable.  This approach is a bit
> more risky, since retrieved shadow entry not dropped immediately.  But it is
> in memory anyway, since getspnam() uses stdio for this...
> But you can control this (a bit tricky) retrieving of shadow info in _one_
> place!

This sounds reasonable to me, at least in principle.

> Little side note.  I see Steve are fun of pam_unix... :) (smile!) Authors? :)

I've contributed to pam_unix, yes. :)  But I'm more worried about the
/process/ here than I am about whether my code gets used.  The prospect of
throwing out the current code and rewriting from scratch worries me.  Basic
unix authentication is a /very/ important feature for PAM to get right, and
for a long time, I think the lack of a good pam_unix module hurt Linux-PAM's
adoption.  We have a module now that, for all its warts, does a good job of
unix authentication, and I think it would be unwise to throw it away.
Incremental changes make it easier to see what was changed, and make it less
likely that new bugs will be introduced.

> And, -- can anyone point me to the SuSe implementation of pam_unix?
> Or, better, maybe someone from Suse who have deal with suse's pam_unix
> reading this?

Thorsten Kukuk is the author of the SuSE module, I believe.

Steve Langasek
postmodern programmer

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