| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
Quoting Tomas Mraz <tmraz@xxxxxxxxxx>:
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
_______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
|
|