Open stephensmalley opened 4 years ago
NFS case fixed via 28d4d0e16f09c1865e2ec8a7d89ca7057a5cf7ae, btrfs remains broken AFAIK.
FTR, the NFS fix eventually ended up in Linus's tree with ID: 779df6a5480f1307d51b66ea72352be592265cad
I believe the commit mentioned above fixes a different issue (https://bugzilla.redhat.com/show_bug.cgi?id=1660798). I'm still able to reproduce the NFS fsconfig(2)
issue on recent kernels. The NFS version seems to be limited to rootcontext=
(possibly others) and, contrary to the original report, I observe the regular mount
failing with rootcontext=
as well. The NFS and BTRFS bugs seem to have different root causes... I believe I'm close to finding (good) fixes for each of them. Hopefully I'll have some postable patches soon.
As reported in https://lore.kernel.org/selinux/c02674c970fa292610402aa866c4068772d9ad4e.camel@btinternet.com/ and https://lore.kernel.org/selinux/afa57a834d8643886f6e0d743c3ee04eecd85fe9.camel@btinternet.com/, the new fsconfig(2) system call will fail if one attempts to specify one or more of the SELinux context mount option on a nfs or btrfs mount. Both nfs and btrfs make their own calls to the security_sb_set_mnt_opts() LSM hook in addition to the call made from the vfs (fs/super.c:vfs_get_tree). As a result, multiple calls are made to the hook with different options (NULL versus non-NULL), which triggers an error from SELinux due to inconsistent application of security labeling options to a single superblock. It is not clear how to fix this in a manner that still preserves normal nfs and btrfs option handling (aside from dropping the SELinux checks and letting last-call-to-hook "win"). No response from the vfs developers to date. Adding this issue to keep track of this bug until such a time as it gets fixed.