Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 07 Nov 2022 11:36:56 +0100
From: Florian Weimer <>
To: Rich Felker <>
Subject: Re: Per-thread file system attributes

* 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)
>>   <>
>> 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

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.


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.