[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221107160817.GF29905@brightrain.aerifal.cx>
Date: Mon, 7 Nov 2022 11:08:18 -0500
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Subject: Re: Per-thread file system attributes
On Mon, Nov 07, 2022 at 11:36:56AM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Tue, Oct 25, 2022 at 12:07:02AM +0200, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> > On Mon, Oct 24, 2022 at 06:41:51PM +0200, Florian Weimer wrote:
> >> >> Some userspace file servers (e.g. Samba) want to change the current
> >> >> directory (or chroot or umask) on individual threads, rather than
> >> >> affecting the entire process. In some cases, this can avoid a userspace
> >> >> emulation of kernel pathname resolution.
> >> >
> >> > Isn't this what the *at() functions were for? Why do we need a second
> >> > solution to the same problem?
> >>
> >> Samba uses it to emulate the missing fgetxattrat interface. I've now
> >> asked why they don't use a /proc-based approach:
> >>
> >> vfswrap_getxattrat_do_async and unshare(CLONE_FS)
> >> <https://lists.samba.org/archive/samba-technical/2022-October/137716.html>
> >>
> >> I need to check the other userspace file servers if they use
> >> unshare(CLONE_FS).
>
> The usage in Samba appears to be unnecessary, but virtiofsd (something
> used in the context of QEMU) apparently needs unshare(CLONE_FS) to
> implement FUSE umask handling correctly:
>
> [Virtio-fs] Use of unshare(CLONE_FS) in virtiofsd
> <https://listman.redhat.com/archives/virtio-fs/2022-November/005178.html>
>
> Both projects ran into issues around syscall filtering for unshare.
> That would be side-stepped if we did it at clone time.
>
> >> Direct system calls for setresuid etc. are more common, I think. They
> >> avoid the setXid broadcast on Linux (to switch over the entire process
> >> to different credentials) and thus can be used to implement per-thread
> >> credentials.
> >
> > The "filesystem uid/gid" extension Linux has (setfsuid/setfsgid) is
> > already per-thread by convention due glibc choosing (and musl & uclibc
> > doing likewise) not to make it process-global with a broadcast. It's a
> > lot more suitable than overloading the POSIX real/effective/saved
> > uid/gid for this purpose, as the latter are intended as security
> > boundaries and the "fs" ones are just intended for implementing file
> > servers.
>
> setfsuid/setfsgid have been deprecated since the switch to different
> setresuid semantics in the kernel. And you could never use them to
> handle supplementary groups, I think.
Do you have a reference for that change? I was unaware of it. This
seems rather unfortunate.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
