Messages in this thread | | | From | Olga Kornievskaia <> | Date | Fri, 17 Dec 2021 16:08:32 -0500 | Subject | Re: [GIT PULL] SELinux fixes for v5.16 (#3) |
| |
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
| |