Login PAM interaction suspect

[David Mitton]

Quoting Thorsten Kukuk <kukuk at suse.de>:

> On Wed, Nov 16, David Mitton wrote:
>
>> Quoting Nicolas François <nekral.lists at gmail.com>:
>>
>>> Hello,
>>>
>>> On Wed, Nov 16, 2011 at 10:38:55AM -0500, David Mitton wrote:
>>>>
>>>> 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.
>>>
>>> OK. I see your point and getpwnam() should be delayed as much as possible.
>>>
>>> However, login is required to setuid(<UID>) / setgid(<GID>) before
>>> setcred, and <UID> or <GID> can only be found using getpwnam(PAM_USER).
>>
>> Why would that be?
>
> Because else pam_setcred cannot modify them and calling them
> afterwards would invalidate all changes pam_setcred() is doing.
>
>> and where is it written?
>
> Did you ever read the manual page about pam_setcred()?
>
> "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."
>

Yes, I have read the man page; I'm still working on the first  
paragraph that says:

The pam_setcred function is used to establish, maintain and delete the  
credentials of a user. It should be called to set the credentials  
after a user has been authenticated and before a session is opened for  
the user (with pam_open_session(3)).
<end quote>

Which was the first thing I saw login do wrong.  It calls  
pam_open_session before pam_setcred.  I'm waiting for someone to  
explain that.

The scope of what it means to set credentials is obscure here.
Since typically credentials are username and password and they are  
either stored in a local file or a remote server.  Not clear what is  
to be done in this local application.  My inutition tells me we are  
talking about some sort of proof of authentication storage, or caching  
for session resumption.

In my application there are no long term credential storage happening  
in my PAM module, or any desire/attempt to directly change the process  
context that it is running in.
I can see if there was a need for a PAM module to store things in the  
user's context, like a Kerberos ticket, that this interaction is  
important.  I wish the docs would explain things like that in a more  
straight forward way.

What really needs to be spelled out here is the expected interation  
(or lack there of) between PAM APIs and the system databases.  The  
mixing of the term "credentials" is confusing.
The UID and GID are not credentials in the typical authentication sense.
They are identifiers and authorization attributes of the user's account.
But that's just my AAA experience talking.

Spelling out when/where process context switches may happen during the  
PAM interaction is also very important.  The UID explanation on the  
man page is important but obscure.

I suspect most LDAP accesses don't have this problem as all the  
information got cached upon authentication.  Certainly moot for file  
based systems.

Also, I've spent much more time with the 3 PAM Guides than the man  
pages.  Similar observations apply.


Dave.

>   Thorsten
>
> --
> Thorsten Kukuk, Project Manager/Release Manager SLES
> SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
>
> _______________________________________________
> Pam-list mailing list
> Pam-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pam-list
>