Login PAM interaction suspect

[David Mitton]

Quoting Tomas Mraz <tmraz at redhat.com>:

> On Thu, 2011-11-17 at 16:59 +0100, Thorsten Kukuk wrote:
>> On Thu, Nov 17, David Mitton wrote:
>>
>>
>> > 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.
>>
>> As I think somebody wrote already here: it's a bug in login where
>> I did send already a patch upstream.
>
> Note that the original PAM RFC has an example where the pam_setcred() is
> called AFTER the pam_open_session(). This conflict with the manual page
> was never resolved one way or another. Some applications prefer calling
> pam_setcred() twice with PAM_ESTABLISH_CRED before pam_open_session()
> and with PAM_REINITIALIZE_CRED after pam_open_session().
>
> Also for David, I'd really say, that what you want to do is really a
> hack as the correct thing would be to write a proper nsswitch module or
> to use an existing one. And if you insist on such a hack you should
> really use pam_acct_mgmt() call to put the user into the
> local /etc/passwd instead of relying on pam_setcred() behavior in one
> way or another.

I'm sorry, if you read my earlier messages, I am writting an nsswitch  
module, the issue was _when_ my nsswitch got the information  
_relative_ to the PAM processing.  My first read of the documentation  
was that it would make sense to do that at pam_setcred() time.  My  
read of login has convinced me otherwise.

Now, I'm not really sure what the purpose of pam_setcred is.   Though  
the point of the setting of UID before calling is telling.  I have no  
need to store any credentials using the user's privs.  I can see that  
if you need to store a proof of authentication credential (Kerberos  
ticket) or are doing some sort of SSO.  But that's never explained.

Dave.

> --
> Tomas Mraz
> No matter how far down the wrong road you've gone, turn back.
>                                               Turkish proverb