From: Stephen Smalley <stephen.smalley.work@gmail.com>
To: Richard Haines <richard_c_haines@btinternet.com>
Cc: Scott Mayhew <smayhew@redhat.com>,
trond.myklebust@hammerspace.com, anna.schumaker@netapp.com,
bfields@fieldses.org, Paul Moore <paul@paul-moore.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
linux-nfs@vger.kernel.org, SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH] NFS: Ensure security label is set for root inode
Date: Mon, 9 Mar 2020 14:05:34 -0400 [thread overview]
Message-ID: <CAEjxPJ7p2=ajPT2c8qJKwAtv6uwtNAKRwVcg5rzck5B6KNsHUw@mail.gmail.com> (raw)
In-Reply-To: <41dadf5423aa1b9c0910ac3d805e6caf785dec8f.camel@btinternet.com>
On Mon, Mar 9, 2020 at 12:41 PM Richard Haines
<richard_c_haines@btinternet.com> wrote:
>
> On Mon, 2020-03-09 at 09:35 -0400, Stephen Smalley wrote:
> > 1. Mount the same filesystem twice with two different sets of context
> > mount options, check that mount(2) fails with errno EINVAL.
>
> I've tests for the first part already, however with NFS it returns
> EBUSY (using mount(2) or the fixed fsconfig(2)). On ext4, xfs & vfat it
> does return EINVAL. I guess another NFS bug. Also mount(8) ignores the
> error and just carries on. Here is a test using the testsuite mount(2):
Looks like selinux_cmp_sb_context() returns -EBUSY on error instead of -EINVAL.
This goes back to 094f7b69ea738d7d619cba449d2af97159949459 ("selinux:
make security_sb_clone_mnt_opts return an error on context mismatch").
I guess you can just make the test accept either -EINVAL or -EBUSY for
the time being and we'll have to consider
whether we want to change it and what would break if we did.
next prev parent reply other threads:[~2020-03-09 18:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 22:58 [PATCH] NFS: Ensure security label is set for root inode Scott Mayhew
2020-03-04 13:55 ` Richard Haines
2020-03-04 14:37 ` Scott Mayhew
2020-03-04 15:38 ` Stephen Smalley
2020-03-06 22:01 ` Scott Mayhew
2020-03-08 17:47 ` Richard Haines
2020-03-09 13:35 ` Stephen Smalley
2020-03-09 16:41 ` Richard Haines
2020-03-09 18:05 ` Stephen Smalley [this message]
2020-03-10 13:27 ` Richard Haines
2020-03-10 15:20 ` Stephen Smalley
2020-03-09 13:14 ` Stephen Smalley
2020-03-10 15:54 ` Stephen Smalley
2020-03-13 0:52 ` Paul Moore
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='CAEjxPJ7p2=ajPT2c8qJKwAtv6uwtNAKRwVcg5rzck5B6KNsHUw@mail.gmail.com' \
--to=stephen.smalley.work@gmail.com \
--cc=anna.schumaker@netapp.com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=richard_c_haines@btinternet.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.org \
--cc=smayhew@redhat.com \
--cc=trond.myklebust@hammerspace.com \
/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).