From owner-freebsd-security@FreeBSD.ORG  Sun Jun 20 20:35:35 2010
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Delivered-To: freebsd-security@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id EEAB11065673
	for <freebsd-security@freebsd.org>;
	Sun, 20 Jun 2010 20:35:35 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42])
	by mx1.freebsd.org (Postfix) with ESMTP id CACB48FC13
	for <freebsd-security@freebsd.org>;
	Sun, 20 Jun 2010 20:35:35 +0000 (UTC)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41])
	by cyrus.watson.org (Postfix) with ESMTPS id 4EFAB46B66;
	Sun, 20 Jun 2010 16:35:35 -0400 (EDT)
Date: Sun, 20 Jun 2010 21:35:35 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: d@delphij.net
In-Reply-To: <4BBCC9DB.60403@delphij.net>
Message-ID: <alpine.BSF.2.00.1006202129240.85800@fledge.watson.org>
References: <4BBCC9DB.60403@delphij.net>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-security@freebsd.org
Subject: Re: priv_check: check against alternative td?
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Security issues \[members-only posting\]"
	<freebsd-security.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
	<mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
	<mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Jun 2010 20:35:36 -0000


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