linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Piotr Jurkiewicz <piotr.jerzy.jurkiewicz@gmail.com>
To: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	kvm@vger.kernel.org, vgoyal@redhat.com, miklos@szeredi.hu,
	stefanha@redhat.com, dgilbert@redhat.com, sweil@redhat.com,
	swhiteho@redhat.com
Subject: Re: [PATCH 00/52] [RFC] virtio-fs: shared file system for virtual machines
Date: Wed, 12 Dec 2018 18:07:40 +0100	[thread overview]
Message-ID: <dc2e6e0f-ab00-a114-0fc1-e787293a73cf@gmail.com> (raw)

Currently, virtio-9p cannot be used with overlayfs in order to obtain 
Docker-like experience (but with separate kernel) because of file 
attributes problems. I wrote an email about that to qemu-devel almost 
year ago, but it received no attention (I attach its contents below.).

Will virtio-fs avoid these problems? I assume it will be transparent 
from the point of view of file attributes, and not enforce any kind of 
security filtering?

Piotr Jurkiewicz

----

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 
zeroed 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.

             reply	other threads:[~2018-12-12 17:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 17:07 Piotr Jurkiewicz [this message]
2018-12-12 21:25 ` [PATCH 00/52] [RFC] virtio-fs: shared file system for virtual machines Vivek Goyal
  -- strict thread matches above, loose matches on Subject: below --
2018-12-10 17:12 Vivek Goyal
2018-12-11 12:54 ` Stefan Hajnoczi
2018-12-12 20:30 ` Konrad Rzeszutek Wilk
2018-12-12 21:22   ` Vivek Goyal
2019-02-12 15:56 ` Aneesh Kumar K.V
2019-02-12 18:57   ` Vivek Goyal

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=dc2e6e0f-ab00-a114-0fc1-e787293a73cf@gmail.com \
    --to=piotr.jerzy.jurkiewicz@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=stefanha@redhat.com \
    --cc=sweil@redhat.com \
    --cc=swhiteho@redhat.com \
    --cc=vgoyal@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 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).