Re: [PATCH 00/26] Fixing wait, exit, ptrace, exec, and CLONE_THREAD

Aleksa Sarai [off-list ref] writes:

quoted

Another easy entry point is to see that a multi-threaded setuid won't
change the credentials on a zombie thread group leader.  Which can allow
sending signals to a process that the credential change should forbid.
This is in violation of posix and the semantics we attempt to enforce in
linux.

I might be completely wrong on this point (and I haven't looked at the patches),
but I was under the impression that multi-threaded set[ug]id was implemented in
userspace (by glibc's nptl(7) library that uses RT signals internally to get
each thread to update their credentials). And given that, I wouldn't be
surprised (as a user) that zombie threads will have stale credentials (glibc
isn't running in those threads anymore).

Am I mistaken in that belief?

Would you be surprised if you learned that if your first thread
exits, it will become a zombie and persist for the lifetime of your
process?

Furthermore all non-thread specific signals will permission check
against that first zombie thread.

Which I think makes this surprising even if you know that setuid is
implemented in userspace.

Eric

On 06/07/2017 09:36 PM, Eric W. Biederman wrote:

quoted

quoted

Another easy entry point is to see that a multi-threaded setuid won't
change the credentials on a zombie thread group leader.  Which can allow
sending signals to a process that the credential change should forbid.
This is in violation of posix and the semantics we attempt to enforce in
linux.

I might be completely wrong on this point (and I haven't looked at the patches),
but I was under the impression that multi-threaded set[ug]id was implemented in
userspace (by glibc's nptl(7) library that uses RT signals internally to get
each thread to update their credentials). And given that, I wouldn't be
surprised (as a user) that zombie threads will have stale credentials (glibc
isn't running in those threads anymore).

Am I mistaken in that belief?

Would you be surprised if you learned that if your first thread
exits, it will become a zombie and persist for the lifetime of your
process?

Furthermore all non-thread specific signals will permission check
against that first zombie thread.

Ah okay, so it really is a matter of Linux's threadgroup semantics just 
not being "right" on a more fundamental level than nptl.

Which I think makes this surprising even if you know that setuid is
implemented in userspace.

Quite surprising, thanks for the explanation.

-- 
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/