selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Haines <richard_c_haines@btinternet.com>
To: linux-fsdevel@vger.kernel.org
Cc: selinux@vger.kernel.org, dhowells@redhat.com,
	viro@zeniv.linux.org.uk, sds@tycho.nsa.gov, paul@paul-moore.com,
	omosnace@redhat.com
Subject: Re: Test to trace kernel bug in fsconfig(2) with nfs
Date: Sat, 08 Feb 2020 17:20:37 +0000	[thread overview]
Message-ID: <afa57a834d8643886f6e0d743c3ee04eecd85fe9.camel@btinternet.com> (raw)
In-Reply-To: <a9a96ab099d6799f67a087910ba8b707d3b87add.camel@btinternet.com>

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





      reply	other threads:[~2020-02-08 17:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 10:12 Test to trace kernel bug in fsconfig(2) with nfs Richard Haines
2020-02-08 17:20 ` Richard Haines [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afa57a834d8643886f6e0d743c3ee04eecd85fe9.camel@btinternet.com \
    --to=richard_c_haines@btinternet.com \
    --cc=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).