-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/29/2013 06:50 PM, Lennart Poettering wrote: > 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? > Circling back around on this, we contacted the kernel keyring developers (specifically David Howells) and we are now working this direction. We initially expected a great deal more resistance than we actually got, which was why we hesitated to take this approach (that and past history with size issues). So the current approach we are investigating looks something like the following (based on discussions between Simo, Nalin, David and myself) 1) We will add a new key type "big_key" that allows us to create keys up to 1MiB in size, backed by internal kernel tmpfs, allowing the contents to be swapped out to disk (unlike most other keyrings, which remain in unswappable kernel memory). 2) We will create a new public interface, keyctl_get_krbcache(uid_t, key_serial_t id). This API will allow the user (and certain privileged root processes such as rpc.gssd and gss-proxy) to access the keys for a particular UID. This keyring shall not be tied to a session (so it can outlive a user on the system if they need to perform actions while not logged in, such as access to secure NFS). The kernel keyring should be created automatically on the first request if it does not yet exist. It must also be possible to manipulate the lifetime timer with functions like keyctl_set_timeout() (to align the keyring life with the credential validity) and must also be possible to be destroyed immediately using the usual keyctl APIs (such as in the kdestroy case). libkrb5 will now accept a new value for the credential cache string (for example: when used in KRB5CCNAME). It will take the form: KEYRING:krbcache:$UID to represent a credential cache collection and KEYRING:krbcache:$UID:tktXXXXX to represent a specific key within a cache collection. This new interface will need to support the 'kswitch' kerberos feature for selecting the REALM against which to operate. This plan does not come without risks. It is possible that the kernel and MIT upstream might not accept this new keyring. We believe at the moment (from conversations with them) that this should be considered a low risk. We are currently planning to execute on this plan immediately and quickly. Once this is complete and readied, action *will* be required by some of our downstream dependencies, including (but not limited to): * sssd * openssh * rpc.gssd * gnome-online-accounts -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH6rUoACgkQeiVVYja6o6MbmQCghWRkC9PCg+90O6gZxdk/0TXc BTkAn14MMmaG8qZERb9ru4CUNFCz0Xyv =XqaJ -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
