Chris Jaeger wrote: > > Hi all, > > I am working on a PAM module that maps usernames > during the authentication process. While testing this, > I've encountered two types of applications: those that > refer to pamh to retrieve the username once authentication > is complete (login is the only program of this class that > I've found so far), and those that continue to use the > initial login name they were given (every other program > I've tested (imap, chsh, su, passwd)). I'm wondering Actually there are others that READS user back. To name afew -- pppd, for example, at least patched by redhat, and my own mdpop3d (pop3 daemon). :) > which behavior is the "correct" behavior? Also, a lot The correct one is to retrieve username back from pam. The whole point of PAM, among other things, is that application have NO info about what it "asks" a user when pam calls for a conversation, so, in general case, application will just not know what was a username at all. Many application deals with usernames themselves, and a classic example of this is network services like pop daemon: their *protocol* defines username, and pam's prompts just do not fit here. But for others, like e.g. xdm's login screen, the *meaning* of a username is not defined than using pam. Yes, after auth et all, app should know what user was authenticated, and should call to pam for PAM_USER. Implementing mdpop3d I found very useful to have popd ask pam for a user after auth: suppose that you have virtual mail system, where users uses user.dom.ain as logname, and those "usernames" mapped by some pam module to "clientNNN" user in system -- in this case, username before auth will be "user.dom.ain", and real username after auth, as we should work as, is "clientNNN". > of applications seem to rely on the getpw*() functions > to determine the existence of a user. Is this simply a > case of legacy APIs, or am I abusing the PAM API? See last week's messages on this list about this. The point is that pam+nss doesn't fit well together in all cases. Regards, Michael.
