[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF9ehCXz5Xw8rUsF9io+Kf5knEQ1f2ehRmZWYisxPFjcz1gXcA@mail.gmail.com>
Date: Mon, 24 Oct 2022 14:24:40 -0500
From: Joel Sherrill <joel@...ms.org>
To: libc-coord@...ts.openwall.com
Subject: Re: Per-thread file system attributes
On Mon, Oct 24, 2022 at 11:42 AM Florian Weimer <fweimer@...hat.com> 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.
>
> 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.
>
RTEMS has something like this with this set of APIs which also support
a thread going back to the global environment:
rtems_libio_set_private_env()
rtems_libio_use_global_env()
The names are pretty dreadful but clearly not for the faint of heart. :)
rtems_current_user_env_get() exists but is primarily an internal
helper. Since RTEMS is a link-in run-time with no kernel/user
separation, it is used in macros.
>
> 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?
>
The Linux and RTEMS approach leans to dynamically being able
to alter the process environment. Your proposal makes it an permanent
attribute of a thread. Just a comment.
I'm pretty sure that the few use cases in the RTEMS source
that I know of all would work either way. But any existing use cases from
the broader world of Linux and RTEMS users may be different.
I'll pass this along to the RTEMS community to see what the reaction is.
--joel
>
> 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.
>
>
Content of type "text/html" skipped
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.
