From: Eric Blake <eblake@redhat.com>
To: Greg Kurz <groug@kaod.org>, qemu-devel@nongnu.org
Cc: Leo Gaspard <leo@gaspard.io>
Subject: Re: [Qemu-devel] [PATCH v2 4/4] 9pfs: local: metadata file for the VirtFS root
Date: Tue, 23 May 2017 12:13:17 -0500 [thread overview]
Message-ID: <5222368e-d0de-457b-7f07-5f104860ec56@redhat.com> (raw)
In-Reply-To: <149554996230.23396.14573553304393992709.stgit@bahia.lab.toulouse-stg.fr.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]
On 05/23/2017 09:32 AM, Greg Kurz wrote:
> When using the mapped-file security, credentials are stored in a metadata
> directory located in the parent directory. This is okay for all paths with
> the notable exception of the root path, since we don't want and probably
> can't create a metadata directory above the virtfs directory on the host.
>
> This patch introduces a dedicated metadata file, sitting in the virtfs root
> for this purpose. It relies on the fact that the "." name necessarily refers
> to the virtfs root.
>
> As for the metadata directory, we don't want the client to see this file.
> The current code only cares for readdir() but there are many other places
> to fix actually. The filtering logic is hence put in a separate function.
>
> @@ -478,7 +504,8 @@ static off_t local_telldir(FsContext *ctx, V9fsFidOpenState *fs)
>
> static bool local_is_mapped_file_metadata(FsContext *fs_ctx, const char *name)
> {
> - return !strcmp(name, VIRTFS_META_DIR);
> + return
> + !strcmp(name, VIRTFS_META_DIR) || !strcmp(name, VIRTFS_META_ROOT_FILE);
We have to block VIRTFS_META_DIR at any depth in the hierarchy, but
can/should we change the blocking of VIRTFS_META_ROOT_FILE to only
happen at the root directory, rather than at all directories? On the
other hand, if you can simultaneously map /path/to/a for one mount
point, and /path/to/a/b for another, then the root file for B is visible
at a lower depth than the root file for A, and blocking the metafile
name everywhere means that the mount A can't influence the behavior on
the mount for B.
Not tested, but looks sane, so:
Reviewed-by: Eric Blake <eblake@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2017-05-23 17:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 14:32 [Qemu-devel] [PATCH v2 0/4] 9pfs: local: fix metadata of mapped-file security mode Greg Kurz
2017-05-23 14:32 ` [Qemu-devel] [PATCH v2 1/4] 9pfs: check return value of v9fs_co_name_to_path() Greg Kurz
2017-05-23 14:32 ` [Qemu-devel] [PATCH v2 2/4] 9pfs: local: resolve special directories in paths Greg Kurz
2017-05-23 15:49 ` Eric Blake
2017-05-23 14:32 ` [Qemu-devel] [PATCH v2 3/4] 9pfs: local: simplify file opening Greg Kurz
2017-05-23 15:51 ` Eric Blake
2017-05-23 21:55 ` Greg Kurz
2017-05-23 14:32 ` [Qemu-devel] [PATCH v2 4/4] 9pfs: local: metadata file for the VirtFS root Greg Kurz
2017-05-23 17:13 ` Eric Blake [this message]
2017-05-23 18:47 ` Greg Kurz
2017-05-23 23:08 ` Leo Gaspard
2017-05-24 8:44 ` Greg Kurz
2017-05-23 14:47 ` [Qemu-devel] [PATCH v2 0/4] 9pfs: local: fix metadata of mapped-file security mode no-reply
2017-05-23 15:04 ` Greg Kurz
2017-05-23 22:27 ` Fam Zheng
2017-05-23 22:59 ` Leo Gaspard
2017-05-24 8:54 ` Greg Kurz
2017-05-25 0:38 ` Leo Gaspard
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=5222368e-d0de-457b-7f07-5f104860ec56@redhat.com \
--to=eblake@redhat.com \
--cc=groug@kaod.org \
--cc=leo@gaspard.io \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).