From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-fs-list <virtio-fs@redhat.com>, Max Reitz <mreitz@redhat.com>
Subject: Re: [Virtio-fs] Current file handle status and open questions
Date: Wed, 24 Mar 2021 16:44:53 +0000 [thread overview]
Message-ID: <YFtshUTbNF9omBGv@work-vm> (raw)
In-Reply-To: <YFsnwtUqfmr3e7dI@stefanha-x1.localdomain>
* Stefan Hajnoczi (stefanha@redhat.com) 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?
>
> > 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?).
I'd be surprised if the mount-id was the same between two hosts.
Dave
> Stefan
> _______________________________________________
> Virtio-fs mailing list
> Virtio-fs@redhat.com
> https://listman.redhat.com/mailman/listinfo/virtio-fs
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2021-03-24 16:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-18 17:09 [Virtio-fs] Current file handle status and open questions Max Reitz
2021-03-23 16:39 ` Sergio Lopez
2021-03-24 7:40 ` Max Reitz
2021-03-24 8:51 ` Sergio Lopez
2021-03-23 19:52 ` Vivek Goyal
2021-03-24 8:06 ` Max Reitz
2021-03-24 13:01 ` Vivek Goyal
2021-03-24 11:51 ` Stefan Hajnoczi
2021-03-24 12:28 ` Max Reitz
2021-03-24 13:08 ` Stefan Hajnoczi
2021-03-24 16:44 ` Dr. David Alan Gilbert [this message]
2021-03-24 16:57 ` Max Reitz
2021-03-24 16:54 ` Dr. David Alan Gilbert
2021-04-13 14:05 ` Vivek Goyal
2021-04-13 14:14 ` Max Reitz
2021-04-13 14:56 ` Vivek Goyal
2021-04-13 15:10 ` Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YFtshUTbNF9omBGv@work-vm \
--to=dgilbert@redhat.com \
--cc=mreitz@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-fs@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.