Re: rename user via PAM module?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux