Re: [PATCH] Linux: Implement per-thread user and group IDs

[Florian Weimer <fweimer at redhat dot com>]

* Joseph Myers:

> It has previously been discussed that it would be desirable for the kernel 
> to have whole-process setXid syscalls 
> <https://sourceware.org/glibc/wiki/Development_Todo/Master#setXid_issues>.  
> Given the per-thread ID feature, would you expect any such future kernel 
> feature to provide some way of exempting particular threads from the 
> whole-process syscalls, or would you expect glibc to continue to use the 
> signal-based mechanism in processes with threads with per-thread IDs?

It's hard to know without the exact mechanism, but I think the proposed
interface is compatible with a typical implementation: if we get
something to unshare UIDs/GIDs, we would keep one sharing group for the
main thread and any threads that do not use per-thread IDs, and each
thread with per-thread IDs would be put into a singleton group of its
own.  The semantics would then closely match what we have today with
signal delivery and this patch, which makes the per-thread nature of IDs
sticky (for subthreads).

In today's setting, we could reasily make a thread enter the non-shared
group of threads even if created from a thread with per-thread IDs.  But
I think this is too confusing, so I implemented the inheritance of the
per-thread flag, and this also allows us to use the most likely kernel
extension in this area (if it ever materializes).

Unfortunately, this model is different from the CLONE_FS approach from
the other patch, where it is possible to build hierarchies of threads
sharing or not sharing the file system attributes.  But implementing
something like that would be quite hard without kernel support, and we
can't even know that future kernel support will behave in this way.

Thanks,
Florian