On Mon, Jul 06, 2015 at 04:24:00PM -0500, Eric W. Biederman wrote: > > > On July 6, 2015 3:47:48 PM CDT, Seth Forshee <seth.forshee@xxxxxxxxxxxxx> wrote: > >On Wed, Jul 01, 2015 at 03:41:37PM -0500, Eric W. Biederman wrote: > >> This set of changes also starts enforcing the mount flags of fresh > >> mounts of proc and sysfs are consistent with the existing mount of > >proc > >> and sysfs. I expected this to be the boring part of the work but > >> unfortunately unprivileged userspace winds up mounting fresh copies > >of > >> proc and sysfs with noexec and nosuid clear when root set those flags > >on > >> the previous mount of proc and sysfs. So for now only the atime, > >> read-only and nodev attributes which userspace happens to keep > >> consistent are enforced. Dealing with the noexec and nosuid > >attributes > >> remains for another time. > > > >Sorry to be the bearer of bad news, but I am seeing a regression in lxc > >with 4.2-rc1 due to this change. lxc is doing a fresh mount of sysfs > >that never specifies either read-only or nodev regardless of how sysfs > >has been mounted previously, and this is causing me to see mount > >failures because of the nodev check. > > > >If I comment out only the nodev check then the mount works on my > >system, > >but based on the code in lxc I don't think there's any guarantee at all > >of this mount having flags consistent with previous mounts. > > Seth you are testing your inprogress patchset that > modifies how nodev works aren't you? > > In rc1 nodev is always forced on a mount in a user namespace. > > There is a fairly easy fix to the nodev cleanup in your > patchset, but it takes a few lines of code change in > fs_fully_visible. Essentially after we get the better > nodev enforcement, fs_fully_visible does not need > to bother with nodev. Drat, you're right. I built an unmodified 4.2-rc1 but I apparently I had booted to the wrong kernel when I thought I was testing it. Without the extra patches it's fine; sorry for the noise. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
