* Re: Test to trace kernel bug in fsconfig(2) with nfs
2020-02-06 10:12 Test to trace kernel bug in fsconfig(2) with nfs Richard Haines
@ 2020-02-08 17:20 ` Richard Haines
0 siblings, 0 replies; 2+ messages in thread
From: Richard Haines @ 2020-02-08 17:20 UTC (permalink / raw)
To: linux-fsdevel; +Cc: selinux, dhowells, viro, sds, paul, omosnace
On Thu, 2020-02-06 at 10:12 +0000, Richard Haines wrote:
> The test program 'fsmount.c' sent in [1], can be used along with the
> test script below to show a kernel bug when calling fsconfig(2) with
> any valid option for an nfs mounted filesystem.
>
> This problem is not related to the btrfs bug I reported in [1],
> however
> I suspect that once vanilla NFS options can be set, it may uncover
> the
> same issue as in [1].
>
> [1]
> https://lore.kernel.org/selinux/c02674c970fa292610402aa866c4068772d9ad4e.camel@btinternet.com/T/#u
>
> Copy the statements below into nfs-test.sh and run.
>
> MOUNT=/home # must be a top-level mount
> TESTDIR=$MOUNT/MOUNT-FS-MULTI/selinux-testsuite
> systemctl start nfs-server
> exportfs -orw,no_root_squash,security_label localhost:$MOUNT
> mkdir -p /mnt/selinux-testsuite
> # mount works:
> #mount -t nfs -o
> "vers=4.2,rootcontext=system_u:object_r:unconfined_t:s0"
> localhost:$TESTDIR /mnt/selinux-testsuite
> # Both of these give: Failed fsconfig(2): Invalid argument
> (nfsvers=4.2
> or vers=4.2 fail)
> ./fsmount nfs localhost.localdomain:$TESTDIR /mnt/selinux-testsuite
> "nfsvers=4.2"
> #./fsmount nfs localhost.localdomain:$TESTDIR /mnt/selinux-testsuite
> "nfsvers=4.2,rootcontext=system_u:object_r:unconfined_t:s0"
> umount /mnt/selinux-testsuite
> exportfs -u localhost:$MOUNT
> systemctl stop nfs-server
>
>
The first reason fsconfig(2) would not work in the above test is
because it does not call any helpers. mount(8) uses the mount.nfs(8)
helper to extract further NFS options that need to be used. In the
above example it requires options:
"proto=tcp,clientaddr=127.0.0.1,addr=127.0.0.1" to be added, therefore
the updated script below will resolve that problem. However, there is
still the same issue that affects the btrfs filesystem detailed in [1].
It is that the "rootcontext=.." option will also fail on NFS with a log
message:
"SELinux: mount invalid. Same superblock, different security settings
for (dev 0:44, type nfs4)"
Update script:
MOUNT=/home # must be a top-level mount
TESTDIR=$MOUNT/MOUNT-FS-MULTI/selinux-testsuite
systemctl start nfs-server
exportfs -orw,no_root_squash,security_label localhost:$MOUNT
mkdir -p /mnt/selinux-testsuite
# mount(8) works:
#mount -t nfs -o
"vers=4.2,rootcontext=system_u:object_r:unconfined_t:s0"
localhost:$TESTDIR /mnt/selinux-testsuite
# This will pass as it has options that would be applied by
mount.nfs(8) helper
./fsmount nfs localhost.localdomain:$TESTDIR /mnt/selinux-testsuite
"nfsvers=4.2,proto=tcp,clientaddr=127.0.0.1,addr=127.0.0.1"
# This will fail with fsconfig(2): Invalid argument
#./fsmount nfs localhost.localdomain:$TESTDIR /mnt/selinux-testsuite
"nfsvers=4.2,proto=tcp,clientaddr=127.0.0.1,addr=127.0.0.1,rootcontext=
system_u:object_r:unconfined_t:s0"
# The rootcontext= entry give the following log message: "SELinux:
mount invalid. Same superblock,
# different security settings for (dev 0:44, type nfs4)"
umount /mnt/selinux-testsuite
exportfs -u localhost:$MOUNT
systemctl stop nfs-server
^ permalink raw reply [flat|nested] 2+ messages in thread