From owner-freebsd-arch Sat Jan 5 18:21: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A745937B400 for ; Sat, 5 Jan 2002 18:21:02 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g062KqD85843; Sat, 5 Jan 2002 21:20:52 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 5 Jan 2002 21:20:52 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alfred Perlstein Cc: Terry Lambert , arch@freebsd.org Subject: Re: freeing thread structures. In-Reply-To: <20020105145534.Y82406@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 5 Jan 2002, Alfred Perlstein wrote: > * Terry Lambert [020105 14:48] wrote: > Actually I always thought it was suboptimal the way one had to setuid > back and forth when running as another user, if one could > "setthreaduid()" it would allow somewhat effecient multiplexing of > sperate credentials through an authentication server. > > This of ftpd without needing to fork() to handle non-anonymous > connections. > > I'm sure there's an even smarter way, but it's just something that that > I thought might be cool. I used to think that idea was cool, and now I just think it's evil. The reason to have per-thread credentials in kernel is to reduce the requirement for locking and to allow consistent use of credentials while in kernel. Exposing multiple credentials in userland will introduce a world of unnecessary suffering. And I think it's probably fairly straight forward to argue that POSIX doesn't like it either, since POSIX appears to consider credentials the attribute of a process, not a thread. The risks here are great also: consider cases where a process downgrades its credentials to act on behalf of a user: normally, by-process events such as signals are limited due to the use of the per-process P_SUGID flag. This prevents the downgrade of credentials from leaking privilege in undersirable ways. Finally, look at the case where multiple credentials are supported: if you have any model where kernel schedulable entities don't map into user threads, your credential state now becomes part of the context you have to save/restore at each userland context switch. Also, threaded applications would behave differently using different threading libraries (userland vs. kse ...). Now suppose we implement AIO by using additional threads in userland... much the same will apply. This type of change will substantially change the model, quite possibly violate POSIX, not to mention user expectations, and make it *much* harder to implement things like Mandatory Access Control. Count my vote as a firm vote not to walk down this path of great evil. :-) It's cool, and you could do cute things like neato userland NFS servers, but the opportunities for suffering are excessive. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message