Steve, Thanks for the excellent information. This is stuff I just could not squeeze out of the docs. It's worth mint to me. Unfortunately what you told me is making me (and more importantly the senior designers) think that PAM may not be suitable for the project I'm working on. Fetching credentials is central to my problem and if I have to hack up every pam module to make that happen then it's less work for me to build a similar system with other code we've got sitting around that does fetch creds. Thanks a lot anyway. I'll keep snooping around. I'm going to hang onto this email too for the next time I need pam. - Ben On Tue, Apr 17, 2001 at 12:25:00PM -0500, Steve Langasek wrote: > 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 > > > > _______________________________________________ > > Pam-list@redhat.com > https://listman.redhat.com/mailman/listinfo/pam-list
