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? </off-topic> -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
