Setuid on successful PAM Authentication
matt at ucc.asn.au
Fri Oct 6 15:16:45 WST 2006
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
> 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
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).
More information about the Dropbear