On Mon, 2013-07-29 at 22:50 +0200, Lennart Poettering wrote: > On Fri, 26.07.13 10:48, Simo Sorce (simo@xxxxxxxxxx) 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? Size. > 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. Sure, feel free to go that way, it is a *long* road, and it is simpler to have a daemon that checks for valid credentials and delete expired ones than deal with this in the kernel. The value of the keyring is in using non-swappable memory, if you allow it to swap then it makes no sense to use a custom, complex, kernel interface anymore, files are just simpler and easier to manage for admins and applications and can be protected easily by ACLs and Selinux. > 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. Long term we want to introduce and use a KCM that doesn't require users to directly use and manage cache files, it will use and manage it's own database. Short term we need to fix the pain introduced with more urgency than we are allowed to deal with less critical issues. Yes there is a possibility for users to abuse this space just like there has always been with /tmp, we are not making the situation really any worse than that. If need be we can add a scanning cron job (or daemon or whatever) that will walk through the caches and eliminate those that have expired credentials in them, it wouldn't be too hard to add, just a matter of spending some time on the binary that check this data in a 'safe' way. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
