From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f51.google.com ([209.85.218.51]:36419 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756003AbcEED36 (ORCPT ); Wed, 4 May 2016 23:29:58 -0400 Received: by mail-oi0-f51.google.com with SMTP id x201so89257558oif.3 for ; Wed, 04 May 2016 20:29:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160505022511.GD26977@dastard> References: <1462372014-3786-1-git-send-email-tixxdz@gmail.com> <20160505002314.GB26977@dastard> <20160505022511.GD26977@dastard> From: Andy Lutomirski Date: Wed, 4 May 2016 20:29:33 -0700 Message-ID: Subject: Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems To: Dave Chinner Cc: LSM List , Serge Hallyn , Djalal Harouni , Alban Crequy , Chris Mason , Dongsu Park , "Theodore Ts'o" , "Eric W. Biederman" , Alexander Viro , Miklos Szeredi , Josh Triplett , David Herrmann , Linux FS Devel , "linux-kernel@vger.kernel.org" , Seth Forshee Content-Type: text/plain; charset=UTF-8 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On May 4, 2016 7:25 PM, "Dave Chinner" wrote: > > On Wed, May 04, 2016 at 06:44:14PM -0700, Andy Lutomirski wrote: > > On Wed, May 4, 2016 at 5:23 PM, Dave Chinner wrote: > > > On Wed, May 04, 2016 at 04:26:46PM +0200, Djalal Harouni wrote: > > >> This is version 2 of the VFS:userns support portable root filesystems > > >> RFC. Changes since version 1: > > >> > > >> * Update documentation and remove some ambiguity about the feature. > > >> Based on Josh Triplett comments. > > >> * Use a new email address to send the RFC :-) > > >> > > >> > > >> This RFC tries to explore how to support filesystem operations inside > > >> user namespace using only VFS and a per mount namespace solution. This > > >> allows to take advantage of user namespace separations without > > >> introducing any change at the filesystems level. All this is handled > > >> with the virtual view of mount namespaces. > > > > > > [...] > > > > > >> As an example if the mapping 0:65535 inside mount namespace and outside > > >> is 1000000:1065536, then 0:65535 will be the range that we use to > > >> construct UIDs/GIDs mapping into init_user_ns and use it for on-disk > > >> data. They represent the persistent values that we want to write to the > > >> disk. Therefore, we don't keep track of any UID/GID shift that was applied > > >> before, it gives portability and allows to use the previous mapping > > >> which was freed for another root filesystem... > > > > > > So let me get this straight. Two /isolated/ containers, different > > > UID/GID mappings, sharing the same files and directories. Create a > > > new file in a writeable directory in container 1, namespace > > > information gets stripped from on-disk uid/gid representation. > > > > I think the intent is a totally separate superblock for each > > container. Djalal, am I right? > > I'm pretty sure you can't have multiple superblocks point to the > same backing device. Each superblock would then think it's the sole > owner of the filesystem and all we get out of that is incoherent > caching and a corrupt on-disk filesystem. I meant separate backing stores, too. --Andy > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com