From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH 2/2] LSM/SELinux: inode_{get,set}secctx hooks to access
	LSM security context information.
Date: Thu, 6 Mar 2008 09:07:13 -0500
Message-ID: <20080306140713.GA20087@infradead.org>
References: <1204743288-3461-1-git-send-email-dpquigl@tycho.nsa.gov> <1204743288-3461-3-git-send-email-dpquigl@tycho.nsa.gov> <20080306123013.GB4648@lst.de> <1204811422.1397.205.camel@moss-spartans.epoch.ncsc.mil> <20080306135444.GA5216@infradead.org> <1204812304.1397.213.camel@moss-spartans.epoch.ncsc.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Christoph Hellwig <hch@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	"David P. Quigley" <dpquigl@tycho.nsa.gov>, casey@schaufler-ca.com,
	chrisw@sous-sol.org, jmorris@namei.org, viro@zeniv.linux.org.uk,
	selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
To: Stephen Smalley <sds@tycho.nsa.gov>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from bombadil.infradead.org ([18.85.46.34]:47331 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1763423AbYCFOHY (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 6 Mar 2008 09:07:24 -0500
Content-Disposition: inline
In-Reply-To: <1204812304.1397.213.camel@moss-spartans.epoch.ncsc.mil>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Mar 06, 2008 at 09:05:04AM -0500, Stephen Smalley wrote:
> It isn't truly changing the security context - it is notifying the
> security module on the client side of the security context provided by
> the server for a given inode.  In the case of uids, the nfs client code
> can directly set the inode->i_uid to the server-provided value from the
> fattr, but for the inode->i_security, the nfs client code has to call
> into the security module to set it in-core.
> 
> Maybe they should be different hooks altogether - just not sure what to
> call the incore case.

Ok, this makes a lot more sense.  These defintively should be different
hooks in that case, and no matter what name they have (no good ideas
from me either currently) they should be documented properly in the
kerneldoc to state something like your above message.