Re: prevent containers from turning host filesystem readonly

[ebiederm@xmission.com (Eric W. Biederman)]

"Serge E. Hallyn" <serge@hallyn.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