Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200303225837.1557210-1-smayhew@redhat.com> <6bb287d1687dc87fe9abc11d475b3b9df061f775.camel@btinternet.com>
 <20200304143701.GB3175@aion.usersys.redhat.com> <CAEjxPJ7A1KRJ3+o0-edW3byYBSjGa7=KnU5QaYCiVt6Lq6ZfpA@mail.gmail.com>
 <20200306220132.GD3175@aion.usersys.redhat.com> <dc704637496883ac7c21c196aeae4e1ab37f76fa.camel@btinternet.com>
 <CAEjxPJ6pLLGQ2ywfjkanDNZc1isVV8=6sJmoYFy8shaSGr972A@mail.gmail.com> <41dadf5423aa1b9c0910ac3d805e6caf785dec8f.camel@btinternet.com>
In-Reply-To: <41dadf5423aa1b9c0910ac3d805e6caf785dec8f.camel@btinternet.com>
From:   Stephen Smalley <stephen.smalley.work@gmail.com>
Date:   Mon, 9 Mar 2020 14:05:34 -0400
Message-ID: <CAEjxPJ7p2=ajPT2c8qJKwAtv6uwtNAKRwVcg5rzck5B6KNsHUw@mail.gmail.com>
Subject: Re: [PATCH] NFS: Ensure security label is set for root inode
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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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.