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

[Adhemerval Zanella Netto]

On 11/12/25 09:53, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> 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.
> 
> There are no security implementations because we already provide
> equivalent functionality via unshare.

Yes, but unshare is a Linux-specific ABI not really tied to pthread.  This
pthread extension changes how intrinsically we define process and threads.

> 
>> 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. 
> 
> That's more of a property of chroot and chdir, and not so much 
> 
>> 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.
> 
> Huh.  I had not thought of that.  The manual page doesn't say which task
> is used for writing the coredump.  Is this documented anywhere?

We have at manual/signal.texi

 271 @vindex COREFILE
 272 When one of these program error signals terminates a process, it also
 273 writes a @dfn{core dump file} which records the state of the process at
 274 the time of termination.  The core dump file is named @file{core} and is
 275 written in whichever directory is current in the process at the time.
 276 (On @gnuhurdsystems{}, you can specify the file name for core dumps with
 277 the environment variable @code{COREFILE}.)  The purpose of core dump
 278 files is so that you can examine them with a debugger to investigate
 279 what caused the error.

We will need to extend that this will depend of which thread receives the
signal and the current FS state of thread.

> 
> This is already a pre-existing to some extent.
> 
>> 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.
> 
> It's already used today by some file servers, via unshare.  Rough query:
> 
>   <https://codesearch.debian.net/search?q=unshare.*(CLONE_FS|NEWNS)&literal=0>
> 
> Some if it could possibly be replaced by openat2, but not all kernel
> functionality has *at variants.

And the next question is whether current practice is really the best
approach, even though is currently used.  I still skeptic that with current
Linux sandbox gramewords this is really the best option to provide concurrency
filesystem isolation (specially when mixing CLONE_VM).

We already provide posix_spawnattr_setcgroup_np to create newly processes
with different cgroupv2, and I think Landlock seems a better approach than
unshare (although I need to dig better in its abi).