On Tue, Oct 03, 2006 at 10:19:17AM -0500, Thaddeus Ternes wrote: > I have (what I believe) to be a unique development case that I'm > interested in some input on. I'd like to add support to my PAM-based > system to map valid PAM authentications back to a certain /etc/passwd > user. ... > However, I'm finding out that most applications implementing PAM > support don't do a check for a username change after a successful PAM > authentication. Instead, the PAM authentication succeeds, and then > the application will call getpwnam() on the radius username, rather > than getting the PAM_USER value from PAM after the authentication. > Perhaps what I'm looking for is beyond what PAM is really intended, > and I'll have to find some other means to accomplish this. However, I > don't see this being isolated to just radius authentications. In the > future, I may wish to authenticate my system against some other > infrastructure (say LDAP), where any user in the "administrators" > group is allowed access to my device. > > Any suggestions on an approach that might be appropriate? All I've > come up with to date is patching the applications I hope to support on > my system (dropbear, and ftpd, and possibly samba). If this is the > *right* approach, I'm fine with that. I'd like to solve this with the > most correct approach.
Using PAM_USER does seem correct, given the PAM docs seem to give your use case as an example: "PAM_USER - ... That is, following authentication, PAM_USER identifies the local entity that gets to use the service. Note, this value can be mapped from something (eg., "anonymous") to something else (eg. "guest119") by any module in the PAM stack. As such an application should consult the value of PAM_USER after each call to a PAM function." If apps don't currently support it then I guess the most correct way to fix it would be to fix the apps, yeah. It's worth noting that Dropbear's PAM support is pretty rudimentary - it will only work if the pam module just asks for Login:/Password:. It completely ignores PAM_USER, though that part would be reasonably easy to fix. Allowing for arbitrary interactive authentication would require some changes. One method (used by OpenSSH) would be to spawn a separate helper process/thread to handle the PAM conversation. An alternatively might be to recursively re-enter Dropbear's main select() loop to send the auth prompt to the client, then return back through the conversation function when the response is received (this is a bit ugly, would require careful checking of assumptions about static variables etc). Cheers, Matt
