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

[Florian Weimer]

* 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.

> 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?

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.

Thanks,
Florian