On 11/12/2012 4:43 PM, J. Bruce Fields wrote:
On Mon, Nov 12, 2012 at 02:36:09PM -0500, David P. Quigley wrote:
On 11/12/2012 11:36 AM, J. Bruce Fields wrote:
On Mon, Nov 12, 2012 at 09:56:37AM -0500, Dave Quigley wrote:
On 11/12/2012 7:15 AM, J. Bruce Fields wrote:
On Mon, Nov 12, 2012 at 01:15:36AM -0500, David Quigley wrote:
From: David Quigley<dpquigl@xxxxxxxxxxxxxxx>
The interface to request security labels from user space is the xattr
interface. When requesting the security label from an NFS server it is
important to make sure the requested xattr
I'm confused--clients can't request xattrs from NFS servers. I must be
reading this wrong, but I'm not sure what you meant.
--b.
Generically clients can't use xattrs from NFS servers but the LSM
method for getting labels is through the xattr interface. THe point
of this is if someone selects security.capability that we don't
translate that into a call in labeled nfs to get the security label.
We only want label based LSMs to cause a getfattr on the server to
grab the label and populate the inode with that information.
Currently if you use security.selinux or security.smack then labeled
nfs will handle the translation of that into a get/setfattr on the
security_label attribute in NFSv4.
OK, I think I understand: so this is to help the NFS client implement
the necessary xattr interface for userspace that get and sets security
labels on NFS filesystems?
--b.
Exactly. The problem is we don't want to have LSM specific logic in
so the best we can do is ask if the security.* xattr being accessed
has the proper semantics to be used with Labeled NFS.
OK, thanks. The changelog could probably be clarified (at least make it
clear that this is for the client side.)
Delaying this patch till right before the patch that actually uses it
might also help (and/or even combining those two patches).
--b.
I should be able to rearrange them and change the patch text. Merging
probably isn't a good idea since all of this code is in LSMs so it seems
weird to put it in with the NFS code.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
