[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <m1sjig1xrp.fsf@fess.ebiederm.org>
Date: Sat, 11 Feb 2012 20:27:54 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serge@...lyn.com>
Cc: Serge Hallyn <serge.hallyn@...onical.com>,
Al Viro <viro@...IV.linux.org.uk>,
lkml <linux-kernel@...r.kernel.org>,
Andy Whitcroft <apw@...onical.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Dave Hansen <haveblue@...ibm.com>,
linux-security-module@...r.kernel.org,
Linux Containers <containers@...ts.osdl.org>,
St?phane Graber <stgraber@...ntu.com>,
Daniel Lezcano <daniel.lezcano@...e.fr>
Subject: Re: prevent containers from turning host filesystem readonly
"Serge E. Hallyn" <serge@...lyn.com> writes:
>> Serge let me respectfully suggest that getting the user namespace done
>> will deal with this issue nicely.
>>
>> In the simple case you simply won't be root so remount will just be
>> denied.
>>
>> When/if we allow a limited form of unprivileged mounts in a user
>> namespace your user won't have mounted the filesystem so you should not
>> have the privilege to call remount on the filesystem.
>
> Hm, that's a good point. Though note it'll require the userns code to
> distinguish between the a bind remount and superblock remount. The
> last time we seriously discussed this, that wasn't even on the roadmap.
> It was only going to support fully assigning the whole filesystem to
> a user namespace. In that case, the remount issue doesn't apply anyway
> as the fs isn't shared with another container.
Come to think of it unmounting and remounting is a bit tricky, and
it is a bit parallel to having a disk base filesystem being in one
user namespace. Currently my patches have the rule that everything
maps to the initial user namespace, so using a filesystem from multiple
user namespaces is not a problem.
Unmounting is pretty safe if the rule is that you control the entire
mount namespace.
Remounting though that does become tricky in the unprivileged situation.
I honestly haven't thought through what that permission check should
look like yet.
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