Aleksa Sarai <asarai@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
