On 24.03.21 12:51, Stefan Hajnoczi wrote:
On Thu, Mar 18, 2021 at 06:09:58PM +0100, Max Reitz wrote:
So, overall it seems like it may be workable to extend the in-kernel MAC
verification to allow for persistent keys, but I still have some open
questions, and I don’t know whether I should just defer them until we
get to the point where we need persistency.
It seems worth refining these ideas a little bit further until they
reach solid ground. Then we can be sure that there is at least one
possible solution. At the moment it seems like most the components of a
solution are known but it's not clear how they all fit together - and
they have a nasty tendency of failing to meet the requirements if they
aren't put together in exactly the right way :).
(Of note: If we implement something where a user space process (or
multiple in conjunction) can arbitrarily choose a MAC key, then this
will also be usable for live migration, because you can continue to use
the key from the source on the destination.)
Definitely. Taking migration into account is worthwhile. One question
about that:
Are Linux file handles transferrable between systems? Basic
configurations that come to mind:
1. XFS, brtfs, ext4 on SAN (e.g. FibreChannel SCSI LUN)
2. NFS
I assumed they were in previous discussions but has anyone checked the
file handle implementations to see whether this is really the case?
I’m not exactly sure what you mean. I think you’re asking whether for a
single (shared) filesystem a file handle always works independently of
which Linux instance is using it?
If so, depends on the filesystem, I guess, but for the ones where I know
how file handles work, yes, it does.
XFS and ext4 just have an inode ID plus a generation ID. For XFS, the
generation ID is stored in the inode structure (I don’t know about ext4,
but I assume it’s the same), so this handle has no information that
would change at runtime, it’s just about on-disk information.
I’ve described the NFS handle structure before, the only notable thing
here is the FS ID it contains. If it’s a UUID, I would assume it is
transferrable, because this UUID is part of the on-disk filesystem. If
such a UUID is not available, AFAIA NFS may fall back to a device ID,
which of course may not be transferrable, but that’s a fallback that I
haven’t seen happen.
Final minor question that doesn’t really fit in fully elsewhere: When
generating a MAC over a file handle, should the mount ID be included?
I’m worried that this might definitely break persistency, but I think we
should include some FS ID. Maybe the kernel should query the FS UUID
for this MAC calculation, and use that instead of the mount ID?
This is a good point. If the file handle is not tied to a particular
file system mount then an application can stash a well-known file handle
(e.g. /) from one mount it has full access to and then use open a file
on a mount that it does not have full directory treeaccess to (e.g. a
bind mount/sub-tree?).
Oh, that’s absolutely true. / on XFS at least has the generation ID 0,
so this would absolutely be usable at least for other XFS filesystems.
So we probably do need to include some FS ID, like the UUID.
Max
_______________________________________________
Virtio-fs mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/virtio-fs
