On Mon, 29.07.13 17:25, Simo Sorce (simo@xxxxxxxxxx) wrote: > > 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. Well, the point is that the kernel keyring is by purpose and by semantics pretty much exactly what you guys need. It has expiry logic, access control, namespacing, and it's main purpose is actually handling of authentication tokens. The only issue appears to be object size, but that's totally fixable. I can understand that it is easier to intrdouce a new userspace daemon that works around a kernel limitations, but the right approach is still to just fix the kernel interface. The kernel keyring folks work for Red Hat, have you pinged them? > > 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. What is "KCM"? > 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. So, why don't you revert to using /tmp then? I mean, it appears that you don't like /tmp because of the broken namespace and because it might not be in tmpfs. And then you move it to some place which has equally bad problems, just different ones. This doesn't make things any better, does it? (Especially given that /tmp is tmpfs by default, so your major driver seems to be the exception?) It appears to me the best would be to stay with /tmp for kerberos for as long as nothing appears that is clearly better and solves the issues. Then, work on the kernel keyring, and move to it in the longer run as soon as it can deal with large keys without issues? > 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. Well, tmpfiles does that on /tmp already. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
