Date: Sat, 5 Jan 2002 21:20:52 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: Terry Lambert <tlambert2@mindspring.com>, arch@freebsd.org Subject: Re: freeing thread structures. Message-ID: <Pine.NEB.3.96L.1020105211439.80548A-100000@fledge.watson.org> In-Reply-To: <20020105145534.Y82406@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 5 Jan 2002, Alfred Perlstein wrote: > * Terry Lambert <tlambert2@mindspring.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020105211439.80548A-100000>