All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: virtio-fs@redhat.com, qemu-devel@nongnu.org,
	Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	German Maglione <gmaglione@redhat.com>,
	Sergio Lopez <slp@redhat.com>
Subject: Re: [Virtio-fs] Use of unshare(CLONE_FS) in virtiofsd
Date: Fri, 04 Nov 2022 18:44:39 +0100	[thread overview]
Message-ID: <875yfuzkag.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <Y2UM/C3aYtQwf40M@redhat.com> (Vivek Goyal's message of "Fri, 4 Nov 2022 09:00:44 -0400")

* Vivek Goyal:

>>  The usual
>> recommendation for emulating it is to use openat with O_PATH, and then
>> use getxattr on the virtual /proc/self/fd path.  This needs an
>> additional system call (openat, getxattr, close instead of fchdir,
>> getxattr),
>
> openat(O_PATH) + getxattr(/proc/self/fd) + close() sounds reasonable
> too. Not sure why did we not take that path. May be due to that extra
> syscall or something else.

Thanks.

>> but it avoids the unshare(CLONE_FS) call behind libc's back.
>
> Hmm.., did not know that libc does not like threads calling
> unshare(CLONE_FS). Not sure why that is a problem.

Here's a corner case: We plan to add chroot detection to NSS module
loading (so that we do not load NSS modules after chroot), as a form of
security hardening.  If the application calls unshare(CLONE_FS) and then
chroot, which NSS modules are loaded depends on which threads call NSS
functions.

One could argue that chdir/chroot are problematic, not
unshare(CLONE_FS). 8-)

> BTW, we need separate umask per thread as well. During file creation 
> we might be switching to umask provide in fuse protocol message
> and then switch back. Given multiple therads might be doing this
> creation in parallel, so we ofcourse need this to be per thread
> property.

That's a good point.  That's not something that can be worked around
with *at functions.

> So if your patches for pthread_create() with per thread filesystem
> attributes finally goes upstream, I guess we should be able to
> make use of it and drop unshare(CLONE_FS).

Thank you for the feedback.

Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: virtio-fs@redhat.com,  qemu-devel@nongnu.org,
	 Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>,
	 "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	 Miklos Szeredi <mszeredi@redhat.com>,
	 Stefan Hajnoczi <stefanha@redhat.com>,
	 German Maglione <gmaglione@redhat.com>,
	Sergio Lopez <slp@redhat.com>
Subject: Re: Use of unshare(CLONE_FS) in virtiofsd
Date: Fri, 04 Nov 2022 18:44:39 +0100	[thread overview]
Message-ID: <875yfuzkag.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <Y2UM/C3aYtQwf40M@redhat.com> (Vivek Goyal's message of "Fri, 4 Nov 2022 09:00:44 -0400")

* Vivek Goyal:

>>  The usual
>> recommendation for emulating it is to use openat with O_PATH, and then
>> use getxattr on the virtual /proc/self/fd path.  This needs an
>> additional system call (openat, getxattr, close instead of fchdir,
>> getxattr),
>
> openat(O_PATH) + getxattr(/proc/self/fd) + close() sounds reasonable
> too. Not sure why did we not take that path. May be due to that extra
> syscall or something else.

Thanks.

>> but it avoids the unshare(CLONE_FS) call behind libc's back.
>
> Hmm.., did not know that libc does not like threads calling
> unshare(CLONE_FS). Not sure why that is a problem.

Here's a corner case: We plan to add chroot detection to NSS module
loading (so that we do not load NSS modules after chroot), as a form of
security hardening.  If the application calls unshare(CLONE_FS) and then
chroot, which NSS modules are loaded depends on which threads call NSS
functions.

One could argue that chdir/chroot are problematic, not
unshare(CLONE_FS). 8-)

> BTW, we need separate umask per thread as well. During file creation 
> we might be switching to umask provide in fuse protocol message
> and then switch back. Given multiple therads might be doing this
> creation in parallel, so we ofcourse need this to be per thread
> property.

That's a good point.  That's not something that can be worked around
with *at functions.

> So if your patches for pthread_create() with per thread filesystem
> attributes finally goes upstream, I guess we should be able to
> make use of it and drop unshare(CLONE_FS).

Thank you for the feedback.

Florian



  reply	other threads:[~2022-11-04 17:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-04  7:50 [Virtio-fs] Use of unshare(CLONE_FS) in virtiofsd Florian Weimer
2022-11-04  7:50 ` Florian Weimer
2022-11-04 13:00 ` [Virtio-fs] " Vivek Goyal
2022-11-04 13:00   ` Vivek Goyal
2022-11-04 17:44   ` Florian Weimer [this message]
2022-11-04 17:44     ` Florian Weimer

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=875yfuzkag.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=gmaglione@redhat.com \
    --cc=misono.tomohiro@jp.fujitsu.com \
    --cc=mszeredi@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=slp@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=vgoyal@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.