Quoting Thorsten Kukuk <kukuk@xxxxxxx>:
On Wed, Nov 16, David Mitton wrote:
Quoting Nicolas François <nekral.lists@xxxxxxxxx>:
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
