Eric, Am 15.02.2017 um 07:27 schrieb Eric Biggers: > 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. I agree. > 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. In my case root would install a key (for the whole filesystem) and later the same key needs to be available to *all* users, *forever*. My fear is that some smart userspace component could kill the key at some time. systemd by creating new session, I'm looking at you. Just kidding. ;) Thanks, //richard
