Hi Ben, On Tue, 17 Apr 2001, Ben Johnson wrote: > I'm kind of a newbie in many ways. please bare with me. No matter how > many times I read the documentation I am not understanding which pam > client function should be used to fetch credentials, such as a list of > user groups. is that sort of thing accomplished with pam? I get the > feeling that something similar happens with pam_set_cred() but I don't > want the process's credentials set... I just want to get the description > of credentials. > that's the basic problem. read on if you want to know the full story. The consensus that was reached after much deliberation was that PAM is not the appropriate place to handle management of Unix credentials. If you're wanting to read the credentials instead of setting them, I don't think I need to explain why setting them from PAM is bad. :) And there's no API for passing credential descriptions back to the app from the module. Probably the biggest barrier to this is that there /isn't/ a generic way to describe credentials in such a way that applications can make use of them without having information about the specific type of credential. I see two possible workarounds. First, you could use the pam_putenv() call from your module to pass the group list back to the application as a string; this requires that every application you want to use with this module be able to handle this special token. Second, since only applications running with privileges will be able to change the process's group memberships, you could write an NSS backend which queries a separate database and then populate this database directly from the PAM module using the information received from CRYPTOCard. This way, the additional group memberships would be picked up automatically when the app calls initgroups(). Variations on this would be to have your PAM module add group information directly into the /etc/group file, eliminating the need for a separate NSS backend; or to have the cryptocard module's pam_setcred() function set up a credentials cache on the filesystem à la Kerberos, which your NSS backend uses to re-fetch group information from the cryptocard server as needed. This last mechanism eliminates the problem of garbage collection after root privileges have been dropped, since all you have at that point is a file owned by the user that can be deleted upon pam_setcred(CRED_DELETE). It's also trustworthy, because even though the user can change the contents of the credential cache, this wouldn't allow the user to spoof the server's response. But I've never used cryptocard, so I don't know if this is a technically feasible solution. > I'm building something that will run on a box that has no users. the > box needs to collect authentication info from a connecting user and > modify other daemons/whatnot on the box based on how the user is > authenticated. I have to be able to collect group information and maybe > other types of credentials in a way that is consistent with the method > I'm using for authentication. so when, for example, I'm using an NT > server to authenticate users I have to collect user groups from the NT > server they're authenticating to. This is a far sight easier than the cryptocard case. Unless you're using a Win2K domain in native mode (in which case you have far greater obstacles to overcome), there is a network API that can be used to query NT group memberships against an NT domain. I believe the 'winbind' module in recent Samba CVS provides an NSS module which attempts to do user/group lookups against the NT domain (so-called 'appliance mode'). > on a side note, I don't understand why this isn't the norm. all the > modules I've looked at seem to be able to authenticate using remote > servers but are not capable of using the credentials from the same > remote source. this newbie could be wrong. pam_smb for instance > doesn't mess with domain or local nt groups.... the authenticating user > must have a local account if group info is desired. Show me an NT server that will provide all the information needed to populate password entries (including user's shell and home directory), and I'll tell you how to do all authentication against the NT server without having to do any extra work setting up local accounts... Steve Langasek postmodern programmer
