[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r3lxyif1.fsf@x220.int.ebiederm.org>
Date: Wed, 16 Sep 2015 19:54:26 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Andy Lutomirski <luto@...capital.net>
Cc: Seth Forshee <seth.forshee@...onical.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Jeff Layton <jlayton@...chiereds.net>,
"J. Bruce Fields" <bfields@...ldses.org>,
Serge Hallyn <serge.hallyn@...onical.com>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>,
SELinux-NSA <selinux@...ho.nsa.gov>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
linux-mtd@...ts.infradead.org
Subject: Re: [PATCH v3 2/7] userns: Simpilify MNT_NODEV handling.
Andy Lutomirski <luto@...capital.net> writes:
> On Wed, Sep 16, 2015 at 1:02 PM, Seth Forshee
> <seth.forshee@...onical.com> wrote:
>> From: "Eric W. Biederman" <ebiederm@...ssion.com>
>>
>> - 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@...ssion.com>
>
>> - /* 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.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists