On Tue, 2011-06-14 at 22:25 +0200, Nicolas François wrote:
> Hello,
>
> On Tue, Jun 14, 2011 at 08:04:06PM +0200, Tomas Mraz wrote:
> >
> > There is no such module currently. Also there is a problem that some
> > applications/services that call the PAM library do not work correctly in
> > this situation. Typical example is the OpenSSH sshd that ignores the
> > PAM_USER changes made by modules.
>
> I've been looking for applications that support this. Are there some
> examples?
>
> shadow-utils has a patch in Debian to support it in su, but I've been
> reluctant to push it to the upstream trunk because I'm unsure how an
> application shall react.
>
> First from a formal point of view, the documentation cannot be correct:
>
> PAM_USER
>
> The username of the entity under whose identity service will be given. 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.
>
> As the PAM_USER value is received with a PAM function, PAM_USER should not
> be checked after each call to a PAM function ;)
Yeah, more correct formulation would be "... after each call to a PAM
stack function." - That would limit it to pam_authenticate,
pam_acct_mgmt, pam_chauthtok, pam_open_session, pam_close_session, and
pam_setcred. But I agree that is still too wide list.
> More seriously, I think the list of APIs which could change PAM_USER
> should be restricted.
> With shadow-utils' su, the following PAM sequence is used. I've tried to
> define how I could react to a change of PAM_USER (this is not necessarily
> what su does).
> 1. pam_authenticate
> If PAM_USER changes, I do not really care. PAM_USER is documented to
> be the authenticated user. I can continue running the command as the
> requested user. (In case of sudo, this might be clearer because the
> authenticated user and the user used to execute the command are
> clearly separated).
> 2. pam_acct_mgmt
> 3. (pam_chauthtok)
> PAM_USER would still be the authenticated user (i.e. the account of
> the authenticated user is checked, not the account of the user the
> command is going to be run as)
At this point I would read the PAM_USER and change the user that would
execute the command.
> 4. pam_setcred
> PAM_USER needs to be set to the name of the user we want to run the
> command as before calling pam_setcred.
> If pam_setcred changes PAM_USER I would have a problem because
> (pam_setcred manpage) the UID and GID credentials need to be set
> before. (which I do not do for UID because I need pam_open_session to
> run as root)
Yes, you're correct in the analysis.
> 5. pam_open_session
> For the same reason, pam_setcred need to be called before
> pam_open_session.
> 6. pam_getenvlist
> It is definitely too late to take any PAM_USER changes into
> consideration at this time.
This function does not call modules so there cannot be any PAM_USER changes anymore.
> My feeling is that PAM_USER can only indicate the authenticated user and
> should not be changed outside of pam_start, pam_authenticate,
> pam_acct_mgmt, pam_chauthtok, pam_set_item (when called explicitly to
> change PAM_USER)
>
> Applications which are asked to authenticate and execute as different
> users have to set PAM_USER before pam_setcred.
Applications must set the PAM_USER, if they want to set it at all,
before first pam stack calling function.
> For the other applications, I see 2 possibilities:
> a] reset PAM_USER before pam_setcred.
I am not quite sure what you mean by reset here.
> Maybe check PAM_USER during the authentication so that the right
> information appears in the log files.
> b] Use the new PAM_USER to execute the command, and log the right
> information in the log files.
>
> In case of su, I would be tempted by a] and in case of login, I would be
> tempted by b]
>
> Any hint?
>
> Best Regards,
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
