[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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
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.
