From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [PATCH 00/26] Fixing wait, exit, ptrace, exec, and CLONE_THREAD Date: Wed, 07 Jun 2017 06:36:48 -0500 Message-ID: <87ink8vxkf.fsf@xmission.com> References: <877f0pym71.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Aleksa Sarai's message of "Wed, 7 Jun 2017 05:40:21 +1000") Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Aleksa Sarai Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kees Cook , Roland McGrath , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Containers , Oleg Nesterov , David Howells , Al Viro , Thomas Gleixner , Linus Torvalds , Ingo Molnar , "Michael Kerrisk (man-pages)" List-Id: linux-api@vger.kernel.org Aleksa Sarai writes: >> 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