libc-coord - Re: Per-thread file system attributes

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <874jvs27w9.fsf@oldenburg.str.redhat.com>
Date: Tue, 25 Oct 2022 00:07:02 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: libc-coord@...ts.openwall.com
Subject: Re: Per-thread file system attributes

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

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.  I can see how *that* is necessary for performance, and to
avoid implementing pathname lookup in userspace (which is bad).  I think
you said before that you consider this (multiple credentials in one
address space) very wrong from a security point of view, but it's how
the kernel operates in supervisor mode, so I'm not entirely convinced.

Thanks,
Florian

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.