Date: Sun, 20 Jun 2010 21:35:35 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: d@delphij.net Cc: freebsd-security@freebsd.org Subject: Re: priv_check: check against alternative td? Message-ID: <alpine.BSF.2.00.1006202129240.85800@fledge.watson.org> In-Reply-To: <4BBCC9DB.60403@delphij.net> References: <4BBCC9DB.60403@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Apr 2010, Xin LI wrote:
> It looks like that we have:
>
> KASSERT(td == curthread, ("priv_check: td != curthread"));
>
> In priv_check(). I'm wondering why we need this assertion? i.e. why don't
> we just do priv_check(int priv) and use curthread instead?
Historically, we did allow it, and in principle, we could allow it again. In
most cases, it's not safe, but there are also (in theory) plenty where it is.
Since it wasn't obvious to me that we might not want that in the future, I
chose to leave the KPI the way it was, rather than cause every consumer piece
of kernel code, kernel module, etc, change, and provide this safety belt. My
current belief is that there's not a strong motivation to cause further
massive KPI disruption (there are a lot of callers), so I think we should
leave it as it is.
FWIW, some other systems make a different design choice there (IRIX, for
example).
Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1006202129240.85800>