Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t

[Anand Suveer Jain <asj@kernel.org>]

On 12/9/26 02:12, David Woodhouse wrote:
> On 11 September 2026 17:07:29 BST, Thiago Macieira <thiago.macieira@intel.com> wrote:
>> On Friday, 11 September 2026 07:51:16 Pacific Daylight Time Anand Suveer Jain 
>> wrote:
>>> I wish I had more clarity on how OpenConnect uses the FSID before I
>>> comment. Do you know? Can you shed some light on this?
>>
>> It's openconnect's option --key-password-from-fsid. It uses the FSID encoded 
>> in hex format as the key's passphrase.
>>
>> To reproduce, take any key without a password and do:
>>  openssl rsa -in unencrypted-key.pem -out encrypted-key.pem
>> And paste your FSID as the password.
>>
>> This is not real security, we all agree. David W can probably remember better 
>> why this option exists, but I would suspect it was an IT mandate that a) the 
>> key not be left unencrypted on disk and b) be specific to a given machine, 
>> avoiding reuse by being copied to another. Ideally, we'd use TPM these days, 
>> but there are still a lot of systems without it where Linux runs, and 
>> especially a lot of legacy set ups.
>>
>> But very simply, it's the fact that the FSID has been used as a stable 
>> identifier and no longer is if the device in question is not itself stable. 
> 
> Right. This was never "security" per se. 
> 
> In the early days of OpenConnect we were required by Intel IT to match the level of security of the Windows key store. Which basically meant that it would not prevent an *attacker* but would prevent a genuine user who hasn't read (or chooses not to obey) the security policy and wants to copy certificates from one machine to another... for at least five minutes (downloading Jailbreak, in the Windows case, and re-encrying the key, in the Linux case).
> 
> It's not high security but it *does* mean that a key file can't *trivially* be copied from machine to machine. Or recovered in useable form from a backup.
> 

Got it.

> Encrypting it with the FSID of the file system it's stored on did a reasonable job of what it was intended to achieve. And the FSID is supposed to be *stable* and not break on a kernel upgrade. (Isn't it part of the NHS FH too, or is that derived entirely differently?)
> 

Are you referring to NFS file handles? That already works fine
for non-cloned Btrfs. The whole point of this patch was to keep
fsid consistent across mounts for cloned filesystems too, but
it turned out to break backward compatibility for the original
filesystem.

Besides, I don't think your approach works with XFS or F2FS
either or at least it hasn't been tested with dynamic disk
discovery? Both of those derive fsid from dev_t MAJ:MIN,
which isn't guaranteed to stay stable across reboots.

> Of course, you *should* have moved on to using a TPM by now; I don't buy the excuse that it isn't available. But still, the kernel shouldn't break userspace *even* if you deserve it for still using this hack in 2026.
Fair point the patch definitely isn't ready for Stable
kernel as-is. I'll get a backport-friendly fix out asap.

Thanks
Anand