On Sep 16, 2015 6:01 PM, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> wrote:
>
> Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes:
>
> > On Wed, Sep 16, 2015 at 1:02 PM, Seth Forshee
> > <seth.forshee@xxxxxxxxxxxxx> wrote:
> >> From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
> >>
> >> - Consolidate the testing if a device node may be opened in a new
> >> function may_open_dev.
> >>
> >> - Move the check for allowing access to device nodes on filesystems
> >> not mounted in the initial user namespace from mount time to open
> >> time and include it in may_open_dev.
> >>
> >> This set of changes removes the implicit adding of MNT_NODEV which
> >> simplifies the logic in fs/namespace.c and removes a potentially
> >> problematic user visible difference in how normal and unprivileged
> >> mount namespaces work.
> >>
> >> Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
> >
> >> - /* Only in special cases allow devices from mounts
> >> - * created outside the initial user namespace.
> >> - */
> >> - if (!(type->fs_flags & FS_USERNS_DEV_MOUNT)) {
> >> - flags |= MS_NODEV;
> >> - mnt_flags |= MNT_NODEV | MNT_LOCK_NODEV;
> >> - }
> >
> > This is an ABI change. It's probably okay, but I think the commit
> > message should make it clear what's happening.
>
> You mean it should include in big flashing neon letters
> ***REGRESSION FIX***
> ?
>
> It is longer in coming than I had hoped. But that is part of the reason
> I did not fix the security hole this way. Getting the s_user_ns stuff
> just so has been non-trivial.
>
> I do agree that because this is a user visible change we do need to keep
> our eyes peeled for pieces of userspace software that may depend on the
> exact details of the current behavior.
Yeah. "Removes a potentially problematic user visible difference"
sounds like the difference has been there forever. If it needs to
get backported, people will appreciate it.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
