Russ Allbery wrote:
John Tang Boyland <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
