Login PAM interaction suspect

[David Mitton]

> From: Nicolas François <nekral lists gmail com> To: Pluggable  
> Authentication Modules <pam-list redhat com> Subject: Re: Login PAM  
> interaction suspect Date: Tue, 15 Nov 2011 22:17:52 +0100 Hello,
>
> On Tue, Nov 15, 2011 at 11:57:05AM -0500, David Mitton wrote:
>>
>>  I am designing a PAM module to serve as a backup authentication
>> mechanism for a device when it has lost network connectivity to it's
>> LDAP server.  There is no local password containing file on the
>> system. The credential used has OTP-ish properties and encodes a
>> privilege level as well.
>>  Upon successful authentication, I planned on the module fabricating
>> a one line passwd file that would be timestamped and deleted past
>> usage.
>>  A helper nsslib function will deal with fronting the "user"
>> information to login and the system.
>>
>>  I was wondering which api service to put the logic the builds the
>> authenticated user information.
>>  I was thinking that pam_setcred() would be appropriate.
>
> I have no strong opinion, but this could be pam_authenticate() or
> pam_acct_mgmt().
>
>> 2) The bigger picture:  notice that getpwnam() and initgroups() has
>> been called before any of this.
>>    So if pam_setcred() or pam_open_session() have any effect on
>> PAM_USER, the user database, or the information returned by nss
>> functions they will not be noticed by login.
>
> Note also in the pam_setcred manpage:
>
> 											   On a Linux system the user's
> 	   UID and GID's are credentials too. However, it has been decided that
> 	   these properties (along with the default supplementary groups of which
> 	   the user is a member) are credentials that should be set directly by
> 	   the application and not by PAM. Such credentials should be established,
> 	   by the application, prior to a call to this function. For example,
> 	   initgroups(2) (or equivalent) should have been performed.
>
> (This is usually not completely implemented because pam_open_session may
> need privileges)

I have no intent of having my pam modules change the attributes of the  
running process.
They are communicating with the database module that will provide  
login (or any other PAM authenticating process) with the information  
about the user that just authenticated.  It's up to the authentication  
application (login) to change what it needs based on that info.
I don't wish to commit that information until the point that I know  
that the session will go forward.

>
> PAM_USER is also documented as
> 	   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.
>
>> From an application point of view it would be much easier if the list of
> PAM stack functions which can change PAM_USER were much more limited
> (pam_authenticate, pam_acct_mgmt, (pam_chauthtok?))
>
> I would exclude pam_setcred, pam_open_session and pam_close_session from
> the list because I would not know in the application how to react to such
> change of PAM_USER.
>
> I would exclude other PAM functions because I do not see any use case to
> change PAM_USER in these other functions.

This was discussed in some other forum (which I lost my breadcrumbs to).
It's moot to me, as I currently don't plan on changing that value.
But login should not assume that  getpwnam(PAM_USER) will work until  
committed with a setcred.

In my case, if "alice" logs in, there is no "alice" record for  
getpwnam() to find until my PAM module creates one and passes it to my  
nsslib module.

It seems that the work around is to do it in pam_acct_mgmt, but I  
think it stinks.

Dave.

>
> Best Regards,
> -- 
> Nekral
>