[PATCH 3/5] Linux: Implement per-thread file system attributes

[Adhemerval Zanella Netto]

On 10/12/25 07:25, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 09/12/25 14:31, Florian Weimer wrote:
>>> This commit adds the functions pthread_attr_setperthreadfs_np and
>>> pthread_attr_getperthreadfs_np.
>>>
>>> The implementation is based on suppressing the CLONE_FS clone flag when
>>> creating the new thread.  The new flag is sticky and is applied to
>>> all threads created from a thread with the PTHREAD_PER_THREAD_NP
>>> attribute.
>>
>> Should we add auxiliary functions to get the current per-thread file
>> system attribute, similar to what pthread_setcancelstate does for
>> the second argument?
> 
> It's possible to get this information using pthread_getattr_np as  far
> as glibc concerned, but the result could be misleading because the
> thread may have called unshare directly.
> 
> The kernel only allows us to check if two threads have the same FS, I
> don't think it tells us on which thread the unshare has happened.

I was thinking more in the sense of pthread itself, so a created current
thread could know how it was created.

> 
>>>> +If a thread that has been created with the
>>>> +@code{PTHREAD_PER_THREAD_NP} flag creates further threads, these
>>>> +threads are implicitly created with the @code{PTHREAD_PER_THREAD_NP}
>>>> +flag, ignoring the value of this thread creation attribute.
>>
>> Does it mean that if I create a thread with PTHREAD_PER_THREAD_NP, and
>> later create a thread with PTHREAD_PER_PROCESS_NP from the newly
>> created thread, the PTHREAD_PER_PROCESS_NP will be silent ignored? If
>> so, this seems confusing.
> 
> It's not possible to get out from under this at the kernel level.  We
> would have to reframe it in terms of inheritance (share with the current
> thread, whatever its sharing properties are).

I think we should make clear on the documentation that setting 
PTHREAD_PER_PROCESS_NP on a thread created with PTHREAD_PER_THREAD_NP
will make the newly created thread share the filesystem properties
with the parent thread.

And with this semantic I wonder whether the PROCESS/THREAD is really
the best naming scheme. The semantic is sharing the filesystem 
properties with the calling thread, instead of the POSIX process
modes, so maybe PTHREAD_SHARE_FS_NP and PTHREAD_NEW_FS_NP would be 
better names.

> 
>>>> +(If this behavior is not desirable, it is possible to call
>>>> +@samp{unshare (CLONE_FS)} from the new thread instead of creating it
>>>> +with the @code{PTHREAD_PER_THREAD_NP} flag.)
>>
>> Requering to call a different API to 'undo' the stick bit setup also
>> seems confusing. Why this can't be done at thread creation before
>> calling the user-provded pthread_cancel routine?
> 
> We would need a helper thread that gives us access to the original FS
> and call clone from that.
> 

I am still not fully sure about the security implications of providing 
this extension. It is a POSIX process model violation, even though the 
documentation states that PWD/ROOT/UMASK are not shared.

It means that calls with relative paths using dlopen, system, and popen 
will behave differently depending on the thread's filesystem state. Same 
for things like logging using relative paths. This will require users to 
take extra care when sharing process-wide state for these functionalities. 

Another problem is that core dumps without a correct signal mask will be 
nondeterministic about where and which permissions the kernel will use. 
Again, this will require extra care from users to avoid more pitfalls.

This will make debugging harder. I am not sure if gdb currently keeps 
track of PWD/ROOT/UMASK in per-thread form, and users will now need to 
check /proc/<pid>/task/<tid>/cwd to know which is the current
directory.

So the question is: for what kinds of programming models would this 
extension be useful? If the idea is to provide concurrency with 
filesystem isolation, I do not think CLONE_VM is the best practice.