On Mon, Jun 5, 2017 at 8:46 PM, J . Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Mon, Jun 05, 2017 at 05:21:55PM -0400, Paul Moore wrote: >> On Mon, Jun 5, 2017 at 11:45 AM, Scott Mayhew <smayhew@xxxxxxxxxx> wrote: >> > 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. In a similar fashion, NFSv4.2 mounts mounted >> > with the context= mount option will not show the correct labels because >> > the nfs_server->caps flags of the cloned superblock will still have >> > NFS_CAP_SECURITY_LABEL set. >> > >> > Allowing the NFSv4 client to enable or disable SECURITY_LSM_NATIVE_LABELS >> > behavior will ensure that the SBLABEL_MNT flag has the correct value >> > when the client traverses from an exported path without the >> > "security_label" option to one with the "security_label" option and >> > vice versa. Similarly, checking to see if SECURITY_LSM_NATIVE_LABELS is >> > set upon return from security_sb_clone_mnt_opts() and clearing >> > NFS_CAP_SECURITY_LABEL if necessary will allow the correct labels to >> > be displayed for NFSv4.2 mounts mounted with the context= mount option. >> > >> > Signed-off-by: Scott Mayhew <smayhew@xxxxxxxxxx> >> > --- >> > fs/nfs/super.c | 17 ++++++++++++++++- >> > include/linux/lsm_hooks.h | 4 +++- >> > include/linux/security.h | 8 ++++++-- >> > security/security.c | 7 +++++-- >> > security/selinux/hooks.c | 35 +++++++++++++++++++++++++++++++++-- >> > 5 files changed, 63 insertions(+), 8 deletions(-) >> >> Thanks for sorting this out Scott and Stephen. >> >> NFS folks, any objections to this patch? If not, I'd like to pull >> this into the SELinux tree but I'd like to have an ACK from you before >> I do. > > Looks OK to me, but I think it's Trond or Anna (added to cc) that you > want the ACK from. It's been about four days with not comments from the NFS folks so I'm just going to go ahead and merge this into the selinux/next branch so we can get some more widespread testing. NFS folks, if you want to object please do so a week or two before the next merge window opens, otherwise I'm going to send this patch upstream. Thanks Scott for working on this patch, and everyone else for their comments, testing, and review. -- paul moore www.paul-moore.com -- 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
