Revisited: how to get 'auth' result?

[Dan Yefimov]

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 at nf15.lightwave.net.ru>  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.