Fwd: [libc-coord] Per-thread file system attributes

[Joel Sherrill]

This is similar to our private process environment. Based on this proposal,
what do folks think? Would this work for RTEMS?

--joel

---------- Forwarded message ---------
From: Florian Weimer <fweimer at redhat.com>
Date: Mon, Oct 24, 2022 at 11:42 AM
Subject: [libc-coord] Per-thread file system attributes
To: <libc-coord at lists.openwall.com>


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20221024/e826ffa8/attachment.htm>