gssapi and replay cache

[Marcus Watts]

Previously, Gred Hudson had replied to me,
...
> > Clearly there's an "unlink" happening on the replay cache -
> > I assume that's a side-effect of krb5_rc_dfl_recover_locked().
> 
> I am not certain what is causing the unlink in your use case.  Our code
> should only unlink the file if krb5_rc_dfl_recover() fails for some
> reason--typically if the replay cache doesn't exist.  Is it possible
> that you have a tmp cleaner that operates on /var/tmp?

There's no tmp cleaner involved.  This is a very basic debian install,
nothing fancy.  It's running sysvinit, so systemd isn't in the picture.

I've had a chance to look at this more closely.  The file is actually not
being unlinked, it's being renamed over.  Here's strace output showing this:

25448 1379995618.673195 write(165, "\1\0\0\0\0\216\0\0\0HASH:61374BB7049446F33838AD2661DCA
44F 49:nfs/taipan.private.linuxbox.com at NAJA.LINUXBOX.COM 47:nfs/naja.private.linuxbox.com@
NAJA.LINUXBOX.COM\0\326\375\7\0=\17AR2\0\0\0nfs/taipan.private.linuxbox.com at NAJA.LINUXBOX.
COM\0000\0\0\0nfs/naja.private.linuxbox.com at NAJA.LINUXBOX.COM\0\326\375\7\0=\17AR", 273) =
 273
25448 1379995618.673268 fsync(165)      = 0
25448 1379995618.675398 fsync(164)      = 0
25448 1379995618.675769 rename("/var/tmp/krb5_RCDXvFm6", "/var/tmp/nfs_0") = 0
25448 1379995618.675833 close(164)      = 0
25448 1379995618.675861 dup(165)        = 164
25448 1379995618.675886 fcntl(164, F_SETFD, FD_CLOEXEC) = 0
25448 1379995618.675914 close(165)      = 0
25448 1379995618.675966 write(164, "\1\0\0\0\0\216\0\0\0HASH:0423825092343784E52364C406FDE
859 49:nfs/taipan.private.linuxbox.com at NAJA.LINUXBOX.COM 47:nfs/naja.private.linuxbox.com@
NAJA.LINUXBOX.COM\0\220\310\r\0\342\17AR2\0\0\0nfs/taipan.private.linuxbox.com at NAJA.LINUXB
OX.COM\0000\0\0\0nfs/naja.private.linuxbox.com at NAJA.LINUXBOX.COM\0\220\310\r\0\342\17AR",
273) = 273

I believe this call sequence is the result of "krb5_rc_dfl_expunge_locked",
which can be called from krb5_rc_dfl_store() or krb5_rc_dfl_recover_locked().

There's a comment in the code about rename being "atomic" - which doesn't
help with the open file descriptors in the other live auth contexts.

...
> I think there is a simpler and more valuable change, which is to destroy
> the krb5 auth context (and therefore the replay cache handle) when we
> finish establishing a context, either on the initiator side or the
> acceptor side.  We don't use the krb5 auth context outside of
> {init,accept,delete}_sec_context.c and ser_sctx.c (and there's no value
> in including the auth context during serialization of completed GSS
> contexts).
> 
> (Note that if a gss_cred_id_t is used to initiate or accept the sec
> context, the replay cache handle is bound to the cred rather than the
> context, and would persist until the GSS cred is destroyed.)

I like this change.  While it won't fix the timing hole presumably
created by the rename above, it should at least keep this code from running
ganesha out of file descriptors.

					-Marcus Watts