Sam Morris <[email protected]> writes:
> I looked into this a bit further. As far as I can tell, when sudo calls
> pam_end, pam_krb5's pamk5_context_destroy function should be called (as
> pam_krb5's auth.c line 976 sets it up to be). However the function is
> not called, and so the ticket cache stays behind after sudo dispenses
> with PAM.
I finally got a chance to look at this in detail, and it's a bug in sudo's
PAM handling, although one that's going to be rather hard to fix.
The problem is that sudo calls PAM as follows:
sudo
pam_init
pam_authenticate
pam_acct_mgmt
fork
pam_open_session
execve
pam_close_session
pam_end
In other words, pam_open_session is called in a child process immediately
before an exec, which of course then destroys all PAM state. sudo does
try to call pam_close_session, but since that's called in the parent, it
doesn't have any of the additional information that pam_open_session
recorded (in this case, speciflcally the user's Kerberos ticket cache).
Therefore, pam_close_session can't clean up any resources created by
pam_open_session.
For PAM's resource management to work properly, pam_open_session and
pam_close_session (or pam_end) have to be called in the same execution
context.
The trouble, of course, is that calling pam_open_session in the parent
means any session setup that PAM does will also affect the parent sudo
process, which I suspect sudo is intentionally trying to void.
(For those looking to reproduce this analysis, pam_open_session is called
from policy_init_session by way of the plugin indirection through sudoers,
which in turn is called by exec_setup. exec_setup is called in the child
process by fork_cmnd.)
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
