[OpenAFS] Solaris 10 (x86): pam_afs_session

[Douglas E. Engert]

Russ Allbery wrote:
> John Tang Boyland <boyland@cs.uwm.edu> writes:
> 
>> Now, I notice in the debug log that pam_afs_session gets run twice and
>> the second time decides it has already run and doesn't do anything.
>> This may be because on recommendation, I had added pam_afs_session to
>> the session stack:
>>
>> other   session required        pam_unix_session.so.1
>> other   session required        pam_afs_session.so always_aklog
>>
>> OK. So I remove the pam_afs_session line from the session stack.
>> ....
>> Eureka!  It works now.
>>
>> I guess, when I applied the recommended fixes, one of them (perhaps
>> misunderstood by me) caused a problem that ended up having the same
>> symptoms as the original problem, so I assumed the fixes were useless.
>> (It may also be that in pam_afs_session 1.5 it no longer gives up if it
>> has already run. I'm still using pam_afs_session 1.4)
> 
> That behavior is still the same.  pam_afs_session doesn't set the note
> that it had already run unless your aklog program exits successfully.  So,
> the next question is why aklog is exiting successfully even though it
> didn't get tokens.

Doing some debugging on Solairs 10 (sparc), I thing *ONE* problem is in
the pam_afs_session where it uses WIFEXITED. I think it should use
both  WIFEXITED(result) && WEXITSTATUS(result) == 0

    164      if (waitpid(child, &result, 0) && WIFEXITED(result))
    165      {  /* added to print the result */
    166          pamafs_debug(args, "DEE result=%d",result); /*added to print result */
    167          return PAM_SUCCESS;
    168      }

The above only tested if it exited  but it did not test the exit status.
if (waitpid(child, &result, 0) && WIFEXITED(result) && (WEXITSTATUS(result) == 0))

The result prints as 1024, as the result is a combination
of exit code and a signal.

The other problem is with Solaris 10. With the pam_krb5 and dtlogin
force the use of a user based cache i.e. krb5cc_%uid, if pam_afs_session is
called for a pam_open_session, it might find the previous contents of a cache,
as pam_setcred has not been called to store the cred, which might result is a
very short token lifetime.

At least for dtlogin on Solaris, pam_afs_session should never be called
for pam_open_session, only called for the pam_setcred.

> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444