Re: Error while unlocking encrypted BCacheFS: Required key not available

From: George Hilliard <thirtythreeforty@gmail.com>
To: kent.overstreet@linux.dev
Cc: linux-bcachefs@vger.kernel.org, lkml@inml.grue.cc, martin@lichtvoll.de
Subject: Re: Error while unlocking encrypted BCacheFS: Required key not available
Date: Tue, 16 Jan 2024 11:59:08 -0600	[thread overview]
Message-ID: <CACmrr9gQeXccyS9ZRiR2KnTKnA6EVBCVz_YWcDC3p1mbGqgMSg@mail.gmail.com> (raw)

> The keyring stuff has been a perpetual utter headache.
>
> I've been debating rewriting that stuff to just pass a memfd handle as a
> mount option and rip out keyring usage...
>
> alternately - now that we're pretty much always mounting via the mount
> helper, perhaps it would be a little bit less fragile if the mount
> helper was adding the key to the keyring - that might be worth checking.

I am hitting this exact issue with the same exact baffling behavior (bcachefs
format, keyctl list, bcachefs mount -> fails). I'm on Arch with Linux
6.7.0-arch3-1
and bcachefs-tools 3:1.4.1-1.

Some other folks have found similar problems with other uses of keyctl, see [1].
It appears systemd segments each system service into its own kernel keyring.
Presumably the one bcachefs-tools is writing into, is not the one the kernel is
reading during mount.

The workaround for users is to run:

    keyctl link @u @s

just before running `bcachefs mount`.

I am not enough of an expert with kernel keyrings to know whether the kernel
code, systemd, Arch's packaging, or something else is at fault here.

- George

[1]: https://github.com/NixOS/nixpkgs/issues/32279