Subject: Re: idr_remove
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Jim Houston <jim.houston@ccur.com>
Cc: russell@coker.com.au, linux-kernel@vger.kernel.org
In-Reply-To: <1109096566.1010.53.camel@new.localdomain>
References: <200502192332.54815.russell@coker.com.au>
	 <1109096566.1010.53.camel@new.localdomain>
Content-Type: text/plain
Organization: National Security Agency
Date: Tue, 22 Feb 2005 13:32:48 -0500
Message-Id: <1109097168.15893.41.camel@moss-spartans.epoch.ncsc.mil>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1175
Lines: 25

On Tue, 2005-02-22 at 13:22 -0500, Jim Houston wrote:
> I spent time looking at the pty and selinux code yesterday.
> I had little luck finding where the selinux code hooks into 
> the pty code.

The call to lookup_one_len() by fs/devpts/inode.c:get_node() ultimately
calls permission(...,MAY_EXEC,...) on the devpts root directory, which
will call security_inode_permission() -> selinux_inode_permission() to
check search access to the directory.  Hence, get_node() can fail if
SELinux is enabled and the process has no permission at all to
search /dev/pts.  If it can get that far, then the inode will ultimately
have its security label set upon the d_instantiate() call (via
security_d_instantiate() -> selinux_d_instantiate()), and be
subsequently checked for opens/reads/writes via the
selinux_inode_permission() and selinux_file_permission() hook functions.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/