On 13.11.2008 4:42, Jesse Zbikowski wrote:
Dan, thanks for your comments.
On Wed, Nov 12, 2008 at 7:28 AM, Dan Yefimov<dan@xxxxxxxxxxxxxxxxxxxxx> wrote:
On 12.11.2008 5:18, Jesse Zbikowski wrote:
pam_radius_auth.so
however, at least in my configuration, it is happy to succeed in the
acct request after a different module handled the auth request, which
breaks my scheme.
Thus your scheme is vulnerable in that respect. Rework it. Read pam.conf
manual and look for extended syntax there.
Unfortunately I think that the advanced syntax does not help me here.
I was looking for a way to preserve state between the application
invoking the auth clause and the acct clause. For instance:
if (auth sufficient pam_first.so) {
acct sufficient pam_first.so
} elsif (auth sufficient pam_second.so) {
acct sufficient pam_second.so
}
It looks like this is outside the scope of what pam.conf can express.
In fact. The extended syntax only allows every module to process account stage
while not terminating the stack on some one error. Does it matter if all modules
process the account stage along with one which authenticated the user?
my module would internally call pam_authenticate() /
pam_acct_mgmt() on other PAM services, according to my specifications.
Yes, that's possible, but such a module would be hardly dependent on PAM
internals that can be changed without notice with each PAM release.
If I understand correctly these functions are part of the PAM public
API, so my module should not break any more often than a normal
PAM-aware application.
You forget about reentrancy problems here. PAM functions are not reentrant.
If your
application is dependent on modules used and/or their order, it is broken in
that respect.
It is non-standard because I want the PAM stack to determine the user
credentials (e.g. group membership) rather than the application,
perhaps based on which modules succeed. From man 3 pam_setcred() I
infer that this is not the "PAM" way of doing things -- the
application is supposed to get group membership from "somewhere else".
So I would have to put in a hack to pass group info from my custom
PAM module to the application. I could override one of the
pam_get_item(3) items which I am not using, e.g. use PAM_RHOST to
store the group name.
Don't overcomplicate. Group membership information can be determined not from
"somewhere else", but from getgrent() function family, which rely on NSS. IOW,
you need NSS module complementary to your PAM one. PAM is responsible only for
authentication and authorization.
--
Sincerely Your, Dan.
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
