[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [OT] getpwnam() interface (was Re: PAM and the pwd.h interface)
- From: Adam Slattery <aslattery sunriselinux com>
- To: pam-list redhat com
- Subject: Re: [OT] getpwnam() interface (was Re: PAM and the pwd.h interface)
- Date: Mon, 11 Jun 2001 18:35:02 -0400 (EDT)
> > This thread could get very messy... :)
My prediction has come true.
> > Yes, I have thought about something like this, but not as a pam module. As
> > a pam module it would be impossible because pam has no interface for
> > applications to get information such as the home directory or the shell or
> > even simple things like the uid/gid. PAM simply doesn't do this.
> I think one way to start might be to add a user-profile-attribute-get
> function that takes an optional PAM handle (optional because
> authenticating to the name service may not be necessary).
This would actually be a wonderful solution, but it would further rip
Linux-PAM away from other PAM implementations and I'm not sure how Andrew
would like this. I asked about this a few months ago during one of the
pam_crypt threads but never got anybody's opinion. If this was added,
I would recommend it use a fifth (new) module type. If this is in fact a
viable option that we (pam-list :) would like to pursue, we could then
discuss what functions would be required of this module type. This is the
SPI you talk about below.
So let's go with the idea of some additions to the PAM API. This would be
much simpler, could be implemented much faster, would be more widely
accepted and used, could provide an equivalent end-result, and relies on a
stable and proven API (PAM).
> > What is needed is something above pam and even nss to handle "all" aspects
> > of user authentication as well as a modular interface to replace nss. Such
> > an API would need to have something similar to getpwnam(), but it would
> > also need something like putpwnam().
Actually, the more I think about this, it seems like this could be done in
> Don't get so ambitious. Name services should be mostly read-only. There
> are too many different backend possibilities to be able to write a
> generic write API for name services(*). There's no puthostent(), and not
> just because DNS updates haven't been available till recently.
> There's a lot to think about, and I would rather there were no standard
> write-side API for name services. I'm a sysadmin -- I know how difficult
> name space management can be -- most shops build tools and scripts to
> match their problems and goals. Solutions are needed, but I think they
> should be product-specific, not standard, otherwise I'm afraid we'd get
> stuck with a bad standard. Ever look at XFN?
I think you are wrong here. There should be a generic write API. Of
course, it must be modular. I'm not sure if you were taking that fact into
consideration. Name space management can be difficult, and I strongly
feel that a read-write API would simplify it more than a read-only API.
IMHO, having the ability to both retrieve and set (read-write) user
attributes (shell, home directory, uid, gid, etc) would provide much
greater flexibility than a read-only API.
> int pam_get_user_attr(pam_handle_t pamh, char * user, char * attr, void **val);
> maybe. Type information might be a nice addition:
> int pam_get_user_attr(pam_handle_t pamh, char * user, char * attr, enum
> pam_user_attr_types type, void **val);
> maybe. Multiple values would be nice as well.
Well, I think the second prototype would fit into PAM better (going mainly
by pam_get_item()). This way, the application can request the attribute
it needs directly. Multiple values probably aren't required, but I'm not
> And so on. But then, you also gotta think about the SPI (i.e., the
> interfaces exported by the modules to implement this), including
> stackability considerations (i.e., what's it mean to have multiple
> modules that know different values of a given attribute for the same
> user. And then you need a standard set of attributes to replace
> getpwnam() with, a standard set of attrs to extend getpwnam() with,
Stackability isn't really an issue. If differant "required" modules have
differant information, return failure. Certainly it would take some
planning on the administrator's part to set this up correctly if he/she
wanted to stack this type of module, but it really wouldn't be a problem.
Yes, we would need to decide on a standard set of attributes. Everything
getpwnam() provides should be sufficient; I can't think of anything else
that would be needed by the application, but additional attributes could
be transparently added if we used the second prototype above.
Now, here is another hypothetical problem that is identical to the problem
I was facing with pam_crypt. How do authentication modules obtain these
The main attributes that authentication modules would need are the hashed
token (password) and account expiration information. Coincidentally, these
are the things in /etc/shadow.
The authentication modules would rely on PAM to obtain these attributes.
We can probably do this (for the module) in one of two ways. Either add a
pam_get_item() feature, or create a new call solely for dealing with these
authentication attributes. It would probably be much simpler and much
better to add things to pam_get_item().
Another issue that would arrise is the fact that in order to authenticate
a user, not only must the authentication stack succeed, but the "user
attribute" stack must also succeed if the authentication stack needs
information from the "user attribute" stack.
> Very non-trivial.
Of course, I never said this would be simple :). But this would be cool
and would increase the flexibility of PAM dramatically because it would no
longer rely on nss, just like it doesn't rely on crypt(3) (pam_unix,
pam_pwdb, ...pam_crypt :)
This certainly seems like it could be a wonderful addition to the PAM API.
It would certainly take some work, but it could be done.
> > - Adam Slattery
> > email@example.com
- Adam Slattery
[Date Prev][Date Next] [Thread Prev][Thread Next]