[lkml]   [2018]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-next: manual merge of the selinux tree with the vfs tree
On 11/29/2018 3:51 PM, Al Viro wrote:

I've added linux-security-module to the CC list.

> On Thu, Nov 29, 2018 at 05:23:24PM -0500, Paul Moore wrote:
>>> OK, I will verify that the SELinux submount fix rebased on top of
>>> vfs/work.mount in the way I suggested above passes the same testing
>>> (seliinux-testsuite + NFS crossmnt reproducer). I am now building two
>>> kernels (vfs/work.mount with and without the fix) to test. Let me know
>>> if there is anything more to do.
>> Thanks.
>> The big thing is just making sure that we don't regress on the fix in
>> selinux/next if/when David's mount rework hits Linus' tree.
> FWIW, the whole thing is getting massaged/reordered/etc. and I would
> like some input from you guys at some point - assuming that I recover
> the ability to talk about LSM without obscenities...
> Question: what *should* happen if we try to cross into a submount and find
> that the thing on the other side is already mounted elsewhere, with incompatible
> LSM options? Ditto for referrals, with an extra twist - what if we are given
> 3 alternatives, the first two already mounted elsewhere with incompatible
> options, the third one not mounted anywhere yet?

I fear that the safe answer and the containers answer are likely
to differ. The safe answer has to be to refuse the mount.

> Incidentally, should smack have ->sb_clone_mnt_opts()?

Probably, but I could never figure out what it was for,
and haven't identified a problem with not using it.

 \ /
  Last update: 2018-11-30 01:58    [W:0.065 / U:2.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site