[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Jun 2017 05:40:21 +1000
From: Aleksa Sarai <asarai@...e.de>
To: "Eric W. Biederman" <ebiederm@...ssion.com>,
linux-kernel@...r.kernel.org
Cc: Kees Cook <keescook@...omium.org>,
Roland McGrath <roland@...k.frob.com>,
linux-api@...r.kernel.org,
Linux Containers <containers@...ts.linux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
David Howells <dhowells@...hat.com>,
Al Viro <viro@...IV.linux.org.uk>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Subject: Re: [PATCH 00/26] Fixing wait, exit, ptrace, exec, and CLONE_THREAD
> 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/
Powered by blists - more mailing lists