MIME-Version: 1.0
References: <CAHC9VhS=WgqJgqpQq9J+0Pec9u8e1VnvGwqOimR54wm6TRptVA@mail.gmail.com>
 <CAHk-=wiiqvcA3noHDqJt2=ik5ikQbycdFQ7s=uq70FcGxWgXvg@mail.gmail.com>
In-Reply-To: <CAHk-=wiiqvcA3noHDqJt2=ik5ikQbycdFQ7s=uq70FcGxWgXvg@mail.gmail.com>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Fri, 17 Dec 2021 16:08:32 -0500
Message-ID: <CAN-5tyEKGQu1Y=o8KfsX3q9NkP4XZRos5stwmrT=ZV1hr1fWrQ@mail.gmail.com>
Subject: Re: [GIT PULL] SELinux fixes for v5.16 (#3)
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Paul Moore <paul@paul-moore.com>,
        Olga Kornievskaia <kolga@netapp.com>,
        Anna Schumaker <Anna.Schumaker@netapp.com>,
        Scott Mayhew <smayhew@redhat.com>,
        SElinux list <selinux@vger.kernel.org>,
        LSM List <linux-security-module@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Dec 17, 2021 at 3:29 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Dec 17, 2021 at 12:02 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > Another small SELinux fix for v5.16 to ensure that we don't block on
> > memory allocations while holding a spinlock.  This passes all our
> > tests without problem, please merge this for the next v5.16-rcX
> > release.
>
> Ugh, pulled.
>
> GFP_NOWAIT can very easily fail, so I'm not convinced your tests would
> catch any of the interesting cases.
>
> There is only one single caller of the new
> security_sb_mnt_opts_compat() callback, and I get the feeling that
> maybe we could parse the options first - into a temporary new
> superblock, and then at "test" time (when we're under that sb_lock) it
> could compare that temporary sb with pre-existing ones?
>
> That would also avoid the need for doing that mount option parsing
> over and over and over again for each sb on the 'fs_supers' lists.
>
> I've pulled this, bit it does smell bad to me, and I think that
> original commit 69c4a42d72eb ("lsm,selinux: add new hook to compare
> new mount to an existing mount") and ec1ade6a0448 ("nfs: account for
> selinux security context when deciding to share superblock") may not
> have been fully thought out.

Can you please elaborate on what is problematic with the two patches
you've highlighted. NFS needs a way to determine if the security mount
options have changed between the two mounts in order to determine if
superblock can be shared.

> It may have *looked* like just adding that check  to
> 'nfs_compare_super' was a simple and good idea, but it really doesn't
> look great.
>
> Adding a few more people to the cc.
>
>                  Linus