From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Florian Weimer References: <87r0yj17l6.fsf@oldenburg.str.redhat.com> Date: Fri, 04 Nov 2022 18:44:39 +0100 In-Reply-To: (Vivek Goyal's message of "Fri, 4 Nov 2022 09:00:44 -0400") Message-ID: <875yfuzkag.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Virtio-fs] Use of unshare(CLONE_FS) in virtiofsd List-Id: Development discussions about virtio-fs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vivek Goyal Cc: virtio-fs@redhat.com, qemu-devel@nongnu.org, Misono Tomohiro , "Dr. David Alan Gilbert" , Miklos Szeredi , Stefan Hajnoczi , German Maglione , Sergio Lopez * 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