[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221024212022.GV29905@brightrain.aerifal.cx>
Date: Mon, 24 Oct 2022 17:20:23 -0400
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Subject: Re: Per-thread file system attributes
On Mon, Oct 24, 2022 at 03:07:53PM -0500, Joel Sherrill wrote:
> On Mon, Oct 24, 2022, 2:55 PM Rich Felker <dalias@...c.org> wrote:
>
> > 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?
> >
>
> On RTEMS, the similar capability includes default file mask, chroot,
> effective and actual user and group id, and more.
>
> But you are right, the at* methods handle the cwd part of this. If a
> program uses them.
The file mask is covered pretty much 100% by just passing a mode of 0
at creation time then chmod after creation. The only way this fails to
do the right thing is for fancy synchronization methods where it's
critical that the file come into existence atomically with its correct
permissions.
chroot is covered mostly by the *at() functions, if you just advance
the pointer past any initial '/' and use a different base fd (the
virtual root) when calling them. This doesn't preclude ".." leaving
the virtual root, and doesn't impose any hard access control boundary,
but any time you have code with multiple privilege contexts running in
the same address space, you don't have any hard access control
boundaries.
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.
