Re: Login PAM interaction suspect

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


Quoting Thorsten Kukuk <kukuk@xxxxxxx>:

On Wed, Nov 16, David Mitton wrote:

Quoting Nicolas François <nekral.lists@xxxxxxxxx>:


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.



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 mailing list

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

  Powered by Linux