From: Piotr Jurkiewicz <piotr.jerzy.jurkiewicz@gmail.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Allow to use virtfs as overlayfs upper dir
Date: Wed, 7 Feb 2018 04:48:57 +0100 [thread overview]
Message-ID: <a54566c9-a54d-4d7f-35e3-6f94ae99bc06@gmail.com> (raw)
Hi,
in order to obtain Docker-like experience I am trying to set up
overlayfs merged directory inside VM. Both upper and lower directories
are mounted with virtfs/9pfs from outside of the VM. However, current
implementation of virtfs makes its usage as upper filesystem impossible.
1. Upper filesystem must support the creation of trusted.* extended
attributes.
9pfs has support for getting/setting xattrs, but calls operating on
attributes other than user.* and system.posix_acl_* are dropped.
2. Upper filesystem must provide valid d_type in readdir responses.
This works, but only in case of 'passtrough' and 'none' security models.
In the case of 'mapped-xattr' and 'mapped-file' models, d_type is being
zeroes to DT_UNKNOWN during readdir() call.
All these limitations can be resolved pretty easily, but requires some
design decisions. I can prepare appropriate patches.
Ad. 1.
Why are operations on attributes other than than user.* and
system.posix_acl_* forbidden? Is this due to security reasons?
If so, can we map all of them to user.virtfs namespace, similarly as
system.posix_acl_* are being mapped to user.virtfs.system.posix_acl_* in
'mapping' mode already? This way any trusted/security/system attributes
will be effective only when mounted via virtfs inside VM.
Ad. 2.
local_readdir() can fill entry->d_type with the right DT_* value by
obtaining file type from mapping and translating it with IFTODT() macro.
This would, however, require reading 'user.virtfs.mode' for each
direntry during readdir() call, what can affect performance. If so, this
behavior would probably need to be controlled with some runtime option.
'mapped-xattr' and 'mapped-file' models are essential for running qemu
with overlayfs as non-root, because overlayfs creates device nodes, what
is possible for unprivileged user only with these models.
I am looking forward for your opinions.
Piotr
reply other threads:[~2018-02-07 3:49 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=a54566c9-a54d-4d7f-35e3-6f94ae99bc06@gmail.com \
--to=piotr.jerzy.jurkiewicz@gmail.com \
--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).