Default libkrb5 ccache location

[Lennart Poettering]

On Fri, 26.07.13 10:48, Simo Sorce (simo at redhat.com) wrote:

(Coming back to the original suggestion, now that the XDG_RUNTIME_DIR
thing is ruled out.)

> Recently a number of bugs [1-5] have come up regarding the new default
> Kerberos Ccache location that we changed according to [6].
> 
> We originally thought that reusing the same directory used by
> XDG_USER_DIR was a good idea as systemd/logind would pre-create it for
> us and we'd all be happy.
> 
> Unfortunately it turns out there a re a number of cases where the
> directory is not pre-created for us (sshd, sudo, su) and a number of
> cases where even if we created it out of systemd/logind supervision we'd
> risk it being yanked from under the process that is using it as by
> default systemd/logind uses a refcount system to know when to remove it.
> 
> I have an idea that can solve the problem relatively easily.
> Create a small dbus program (reuse oddjob ?) that will be called by
> libkrb5 to request creation of the credential cache. This would be a
> small Fedora19 patch to libkrb5, I do not think upstream would like it
> in this form (more on it later)[*].
> 
> The dbus program would simply get the unix cred structure of the calling
> application via dbus services and unconditionally
> create /var/kerberos/user/%uidnumber/krbcc[**] directory based
> exclusively on the uid number of the peer and a system configured
> template, it would also create a symlink in /run/user/%uidnumber/krbcc
> for backwards compatibility in Fedora 19 only, and we transition
> completely to the new dir in F20.
> 
> Why a new dir ? Because we do not want systemd/logind to yank the
> directory under us. There are a number of cases where it would be
> beneficial to keep it around (example a cron job that starts every 10
> minutes and uses cached credentials valid for hours to do some task).

So, let me get this straight. You want to avoid any kind of automatic
clean-up, and thus you want to introduce a new runtime directory backed
by tmpfs?

The cleanup mechanisms of XDG_RUNTIME_DIR and /tmp have been introduced
to solve real problems. We should not introduce a new scheme without any
concept of automatic clean-up. /tmp already has awful clean-up
semantics, XDG_RUNTIME_DIR is supposed to make things better, but by
introducing a new user-writable dir which is entirely unrestricted you
go back to start. I think this is a *really bad idea*.

So, one question, why again not just use the kernel keyring? If this is about
the size of the objects then maybe you can convince the kernel keyring
guys to make it backed by tmpfs, the same way as GEM/DRM or kdbus is
backed by tmpfs these days. That makes the memory swappable and somewhat
sanely attributed to the users creating them. The difference between
using raw tmpfs and the keyring is that the keyring actually has
time-based clean-up built in via expiry timeouts.

Anyway, please don't blindly introduce new places where users can
acquire unbounded resources with no scheme of cleaning them up again. We
already have too many places like that, like /dev/shm or SysV IPC which
are entirely unpoliced. Instead of introducing more and more places with
no-cleanup logics we should much rather work on fixing the existing ones.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.