On Mon, Jan 20, 2020 at 10:40 AM Stephen Smalley <stephen.smalley@xxxxxxxxx> wrote: > On Mon, Jan 20, 2020 at 7:52 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > This looks good to me too, thanks Stephen. Because of the nature of > > this fix, I'm going to merge this into next now, even though we are at > > -rc7. Since we are effectively treating this as another mount > > operation, and reusing the file:mounton permission, I don't believe > > there should be any widespread access denials on existing distros ... > > I assume you've at least tested this on Fedora and everything looked > > okay? > > I did basic boot testing plus selinux-testsuite on Fedora without any issues. > I'm not sure that Linux userspace (at least shipped in distros) > besides test/sample programs is using the new system calls yet. > And since anything that performed mounts previously using mount(2) > would have required mounton permission, > I would expect anything converted to use the new system calls would > likewise have that permission already. It is the last sentence that I was getting at in my reply. It seems reasonable to equate moving a mount to mounting a filesystem (which this patch does), and thus any domain which wants, and should have the permission, to move a mounted filesystem is likely to already have the file:mounton permission. -- paul moore www.paul-moore.com
