From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27367 invoked by alias); 20 Sep 2004 19:20:11 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 27349 invoked from network); 20 Sep 2004 19:20:11 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sourceware.org with SMTP; 20 Sep 2004 19:20:11 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 52653357B; Mon, 20 Sep 2004 12:20:10 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.11/8.12.9) with ESMTP id i8KJK9aZ024195; Mon, 20 Sep 2004 12:20:10 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.11/8.12.11/Submit) id i8KJK8Vm024192; Mon, 20 Sep 2004 12:20:08 -0700 Date: Mon, 20 Sep 2004 19:20:00 -0000 Message-Id: <200409201920.i8KJK8Vm024192@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Ulrich Drepper Cc: GNU libc hacker Subject: Re: setXid In-Reply-To: Ulrich Drepper's message of Sunday, 19 September 2004 17:27:01 -0700 <414E23D5.50502@redhat.com> X-Windows: the art of incompetence. X-SW-Source: 2004-09/txt/msg00074.txt.bz2 To be fair, we haven't presented Linus et al with an actual implementation to fix the kernel semantics cleanly. I have talked about some strategies and the response has been quite skeptical. But that was largely the case when talking about numerous other changes to correct Linux semantics to follow POSIX, and when I actually provided the implementations, convincing them to incorporate the code was more possible than initial reactions suggested. But, it's also the case that such an implementation is going to be a bit hairy, and I don't expect to get to it in the next couple of weeks. I won't argue against your desire to have some interim solution. There are a variety of problems with the half-assed user-mode simulation of the correct semantics. I'm pretty sure there is no way a user-mode implementation can actually be POSIX-conformant. I tend to agree that almost-correct is better than the status quo of known-wrong. But we should make sure that users are aware of the limitations of what we have now. The fundamental limitation of not having the kernel support the right semantics directly is nonatomicity: at some point in some race conditions, you will have one thread behaving under one UID and another thread behaving under a different UID in a way that is detectable (if not exploitable). The implementation using signals can also introduce some anomalies common to signal interruption (spurious EINTR returns and suchlike), which are more likely to be an issue than the nonatomicity (unless, of course, that can be badly exploited by an attacker). I have never been in favor of a per-thread ID extension. I am highly skeptical that we want to provide such an extension. I am even doubtful that nscd should be using it. If you want to add these extensions, please give a complete specification (in POSIX terms) of exactly what they mean. It is wholly unclear to me what the EUID of a thread distinct from the process's EUID means, and I would have to consider each and every reference to UIDs or privilege in POSIX to get a handle on it. The manifest semantics of the existing system calls in Linux 2.6 is something that creates real security problems if things like nscd start using it. Now any user can send signals to an nscd thread that is processing a query for its UID. Fortunately a user can't suddenly ptrace nscd--but those are just the first two things I thought to check, and again I would have to audit a lot of kernel code to really be sure what kinds of worms are in this can. AFAICT the useful thing that you are trying to have nscd do is just to assume the user's identity for purposes of filesystem and network access. That is an extension that seems at least somewhat sensible, unlike per-thread EUIDs, which is a total nightmare. For just this, Linux's setfs*id system calls implement it already and perhaps we should just be blessing their use in pthreads programs. Thanks, Roland