Ericm

Am Dienstag, 19. März 2019, 00:08:31 CET schrieb Eric Biggers:

I tried using sb->s_bdi->name, but it's still "ubifs" for all UBIFS filesystems.

hmpf.
 

Perhaps there's a way you can make ->s_id for UBIFS unique?  There are already
existing places that log ->s_id, so perhaps you should do it anyway regardless
of this patchset?

Yes, let me implement that.
ubifs does:
super_setup_bdi_name(sb, "ubifs_%d_%d", c->vi.ubi_num, c->vi.vol_id);

So, I try to set ->s_id also to ubifs_%d_%d.

quoted

quoted

quoted

Note that the keyring name isn't particularly important, since the ioctls will
work regardless.  But we might as well choose something logical, since the
keyring name will still show up in /proc/keys.

I'm not done with reviewing your patches, but will it be possible to use keyctl?
For the a unique name is helpful. :)

Not for adding keys, removing keys, or getting a key's status -- those are what
the ioctls are for.

See e.g. the discussion in patch 7 ("fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY
ioctl") for why the keyrings syscalls are a poor fit for fscrypt.

Anyway, perhaps I should reconsider whether fscrypt should even use the keyrings
subsystem at all, even just "internally", as its quirks still leak out a bit.
I'd prefer a nice clean API without any quirks like having to name the keyrings
and assign SELinux labels to the keys just to make the keyrings subsystem happy.

IMHO the keys subsytem is a good fit. For example for stuff like this one:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1945778.html

We use UBIFS on many embedded systems with crypto hardware.

Thanks,
//richard