[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h6zt2my8.fsf@oldenburg.str.redhat.com>
Date: Mon, 24 Oct 2022 18:41:51 +0200
From: Florian Weimer <fweimer@...hat.com>
To: libc-coord@...ts.openwall.com
Subject: Per-thread file system attributes
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.
On Linux, these file servers current call unshare(CLONE_FS) to achieve
this effect (even without libc support), but I'd rather have a record
inside libc, in case we need to open internal implementation files
spontaneously.
For glibc, I came up with the interfaces described below. It's slightly
convoluted because file servers need even more support in this
direction.
Any suggestions or comments?
Thanks,
Florian
35.2.2.3 Enabling Additional Per-Thread Properties
..................................................
POSIX mandates that the current directory, file system root, umask
value, and the current user and group IDs are process-global properties.
For example, if a thread calls the ‘chdir’ function to change to a
different directory, all threads are eventually affected by this change.
The GNU C Library implements an extension which allows threads to be
created which do not share these properties with the rest of the
process.
The desired behavior is specified at the time the thread is created,
using the thread attribute. The following constants are used to update
the attribute:
‘PTHREAD_PER_PROCESS_NP’
This property in question is globally shared across the entire
process. This is the default.
‘PTHREAD_PER_THREAD_NP’
This property in question is thread-specific.
The ‘PTHREAD_PER_THREAD_NP’ flag is sticky, in the sense that all
threads created by a thread created with this flag have per-thread
properties, even if they are created with the matching thread attribute
set to the ‘PTHREAD_PER_PROCESS_NP’ flag. If an application wants to
create new threads sharing properties with the main thread, it should
create a service thread early (perhaps from an ELF constructor) and
create these threads using this service thread.
Per-thread properties can be set and examined for an attribute using
the functions below.
-- Function: int pthread_attr_setperthreadfs_np (pthread_attr_t *ATTR,
int SCOPE)
| MT-Safe | AS-Safe | AC-Safe | *Note POSIX Safety Concepts::.
Change whether the following properties related to file system
access are made thread-specific when a new thread is created using
the attribute ATTR:
• current directory (as changed by ‘chdir’ and related
functions)
• file system root (as changed by ‘chroot’)
• umask value (as changed by the function of the same name)
This function returns zero on success. SCOPE must be one of the
constants ‘PTHREAD_PER_PROCESS_NP’ or ‘PTHREAD_PER_THREAD_NP’,
otherwise the function returns ‘EINVAL’.
If SCOPE is ‘PTHREAD_PER_THREAD_NP’, the attribute will cause the
properties listed above to be specific to the thread. The initial
values of these properties are copied from the creating thread, at
thread creation time.
If a thread that has been created with the ‘PTHREAD_PER_THREAD_NP’
flag creates further threads, these threads are implicitly created
with the ‘PTHREAD_PER_THREAD_NP’ flag, ignoring the value of this
thread creation attribute.
This function is a GNU extension and specific to Linux.
-- Function: int pthread_attr_getperthreadfs_np (pthread_attr_t
*restrict ATTR, int *restrict SCOPE)
| MT-Safe | AS-Safe | AC-Safe | *Note POSIX Safety Concepts::.
Obtain the per-thread status of the file system properties in ATTR
and store it in the location SCOPE.
This function is a GNU extension and specific to Linux.
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.
