On Fri, May 26, 2017 at 11:17:22AM -0400, J . Bruce Fields wrote: > On Fri, May 26, 2017 at 10:48:17AM -0400, Stephen Smalley wrote: > > On Thu, 2017-05-25 at 17:07 -0400, Scott Mayhew wrote: > > > Red Hat QE reported that chcon fails over NFSv4.2 on recent kernels. > > > The problem is related to how filesystems are mounted in NFSv4. > > > > What kernel version and what is a reproducer for the problem? I don't > > seem to see it on e.g. Fedora 25 with 4.10, unless I misunderstand. > > Basically just mount an export with security_label set, mount over NFS, > "ls -Z" will (correctly) show you the server-side security labels, but > "chcon" will fail with ENOTSUP. > > If that's not reproducing, maybe you chould show us "exports -v" and > "mount" output--it might not reproduce if you have an "fsid=0" export or > if you're mounting with a protocol version older than 4.2. Oh, and, sorry, kernel version: I think you just need something recent enough to support "security_label", which went into 4.11. --b. > > --b. > > > > > > > > > When an NFSv4 client performs a mount operation, it first mounts the > > > NFSv4 root and then does path walk to the exported path and performs > > > a > > > submount on that, cloning the security mount options from the root's > > > superblock to the submount's superblock in the process. > > > > > > Unless the NFS server has an explicit fsid=0 export with the > > > "security_label" option, the NFSv4 root superblock will not have > > > SBLABEL_MNT set, and neither will the submount superblock after > > > cloning > > > the security mount options. As a result, setxattr's of security > > > labels > > > over NFSv4.2 will fail. > > > > > > NFS servers with a modern nfs-utils package will automatically create > > > a > > > pseudo fs to fill in the gaps (including the root itself) leading up > > > to > > > the actual export, so it is uncommon these days for an NFS server to > > > have an explicit fsid=0 export. > > > > > > Allowing the NFSv4 client to override the SECURITY_LSM_NATIVE_LABELS > > > flag on an initialized superblock would ensure that SBLABEL_MNT is > > > set > > > when the client traverses from an exported path without the > > > "security_label" option to one with the "security_label" option. > > > > > > Scott Mayhew (2): > > > selinux: allow SECURITY_LSM_NATIVE_LABELS to be set on an already > > > initialized superblock > > > nfs: update labeling behavior on a superblock when submounting > > > > > > fs/nfs/super.c | 23 ++++++++++++++++++++++- > > > security/selinux/hooks.c | 4 ++-- > > > 2 files changed, 24 insertions(+), 3 deletions(-) > > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
