Re: [PATCH] fs: call security_d_instantiate in d_obtain_alias

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/19/2010 11:42 AM, J. Bruce Fields wrote:
On Fri, Nov 19, 2010 at 12:28:09AM -0500, David Quigley wrote:
[snip]
If you have persistent xattr support we need the dentry since the xattr
code requires a dentry.  I have no idea why but that's what
inode->i_op->getxattr() requires.

The original reason that the xattr operations take dentries is
because of p9fs and CIFS. CIFS uses the name of the file to grab the
extended attributes and so does p9fs. I had tried to remove this a
while ago but couldn't find a way around that.
Both CIFS and FUSE are NFS-exportable, so both allow lookup by
filehandle, so neither can count on getting a filename at this point.

So, out of curiosity, do we know what will happen when selinux asks one
of them for an xattr on a DCACHE_DISCONNECTED dentry?


SELinux uses several methods to determine file labeling. In the policy filesystems such as xfs and the ext* series of filesystems are marked as fs_use_xattr. In this process the file label is pulled from the security.selinux xattr on disk. However CIFS and FUSE (and NFS but our Labeled NFS changes are trying to fix this) all have the filesystem marked as genfs. When mounting the filesystem the fs_type is looked at to determine its labeling type. Since its genfs we lookup what label was determined to be the default for that filesystem type. In NFS's current state all NFS mounts regardless of version get the uniform label of nfs_t for everything listed on an nfs mount point. We have a similar situation for cifs and fuse. So in this case SELinux should not be asking for the security.selinux xattr from these file systems. However if a getxattr call to the security.selinux xattr is made on these filesystems it will still work I might be wrong but my understanding is just the a dentry in the DCACHE_DISCONNECTED state is not negative but just isn't in the tree anymore. So looking at vfs_getxattr I had made some modifications a while back to it. Assuming we have permissions to access the file determined by xattr_permission and security_inode_getxattr we check to see if it is in the security namespace. If it is in the security namespace we call xattr_getsecurity which will attempt to get the security label from the inode first (security_inode_getsecurity). Because the convention is to call d_instantiate on inode create this should always work assuming an LSM is loaded. If it fails and we don't have an lsm loaded we fall back to checking the getxattr i_op and if that doesn't exist we fail with EOPNOTSUPP. That is what should happen on the getxattr call. I don't know if something is happening higher up that makes it so we never get to vfs_getxattr in the event that the dentry is in the DCACHE_DISCONNECTED state. If the DENTRY is disconnected though I'm not sure how getxattr from userspace would be able to have access to it except through a different name in the namespace.

When trying to find a
solution I also got push back from Miklos (FUSE) as he views a
filesystem being able to make xattr decisions based on the path name
being a valid use-case.
So selinux may initialize an inode differently depending on which
pathname it happened to be looked up under first?

Factoring the name into the xattr return sounds scary to me.


The only current use of determining file label from path name is the situation that Eric Paris described with proc. I personally don't agree with miklos that the path to the xattr should make it return different information (unless im understanding him wrong). However the same thing is at work for CIFS as it exposes the windows alternate file streams which are accessed by adding the stream name to the end of the filename with a separator which I can't remember at the moment. If it was the situation that two fuse files shared the same inode and the security.selinux xattr was filled differently if it was accessed via /fuse/foo and /fuse/bar then yes the situation you described might happen. Normally this isn't a problem because file systems don't take the path into account so a hardlink to the same inode will still obtain the same security label. In reality the xattr is a piece of inode metadata and not a piece of dentry metadata.

--b.


--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux