Hi Richard, On Tue, Feb 14, 2017 at 11:51:31AM +0100, Richard Weinberger wrote: > AFACT fscrypt was designed for the Android/ChromeOS use-case to encrypt a home directory. > For this case using keys of type logon makes perfectly sense. > But there are cases where other types would be useful. > Please consider the case where the whole filesystem is encrypted and an initramfs loads > the encryption master key. Here a logon key is not suitable since different users might need > it. > > I suggest adding support for different types to fscrypt_get_crypt_info(). > I.e. such that a filesystem can indicate in ->s_cop that a "global" key ring > should be used. > > What do you think? I think you may be confusing keys and keyrings. "logon" is a type of key, not a type of keyring. The semantics of a "logon" key are that it can be created and updated by userspace, but cannot be read by userspace. (See Documentation/security/keys.txt.) Despite the name it does not need to be tied to an actual user "logging in" per se, and you can add a "logon" key to any keyring, either one of the special ones like a session keyring, or to a manually created one. Also, session keyrings do not need to be tied to other concepts of a "session"; a process can simply set one up, and it gets inherited by children. So it would be possible for init to insert the key into its session keyring, and then all processes would inherit it, unless they explicitly replace it. If I'm not mistaken, Android actually uses a global keyring quite similarly to that. I think the only real difference is that a privileged process on Android adds and removes keys as users log in and out, whereas you'll need to add a key at init time only. Eric
