Message-Id: <20170921003930.GM5698@ram.oc3035372033.ibm.com>
Date:   Wed, 20 Sep 2017 17:39:30 -0700
From:   Ram Pai <linuxram@...ibm.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Dawid Ciezarkiewicz <dawid.ciezarkiewicz@...rik.com>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: Read-only `slaves` with shared subtrees?

On Wed, Sep 20, 2017 at 06:06:55PM -0500, Eric W. Biederman wrote:
> ebiederm@...ssion.com (Eric W. Biederman) writes:
> 
> > Ram Pai <linuxram@...ibm.com> writes:
> >
> >> sorry forgot to copy Eric.
> >
> > Adding fs-devel as well.
> >
> >> On Wed, Sep 20, 2017 at 12:39:54PM -0700, Ram Pai wrote:
> >>> On Tue, Sep 19, 2017 at 04:18:02PM -0700, Dawid Ciezarkiewicz wrote:
> >>> > On Mon, Sep 18, 2017 at 1:47 PM, Ram Pai <linuxram@...ibm.com> wrote:
> >>> > > It is possible to make a slave mount readonly, by  remounting it with
> >>> > > 'ro' flags.
> >>> > >
> >>> > > something like
> >>> > >
> >>> > > mount -o bind,remount,ro <slave-mount-dir>
> >>> > >
> >>> > > Any mount-propagation events reaching a read-only-slave does
> >>> > > inherit the slave attribute. However it does not inherit the
> >>> > > read-only attribute.
> >>> > 
> >>> > I did try manually remounting, and it worked for me. If this could be
> >>> > done atomically
> >>> >  (which I assume can't be, in the userspace) it could even be a workaround.
> >>> > 
> >>> > > Should it inherit? or should it not? -- that has not been thought
> >>> > > off AFAICT. it think we should let it inherit.
> >>> > 
> >>> > It makes sense, and it would work in my use-case. I wonder
> >>> > if that would break any existing expectations though.
> >>> 
> >>> It could break existing expectations, for mounts created by propagation.
> >>> This needs to be thought through. Also Should the same semantics
> >>> apply to MNT_NOSUID, MNT_NOEXEC etc etc? 
> >>> 
> >>> Copying Eric. he should be able to tell if any of the container
> >>> infrastructure assumes anything about mounts propagated to read-only
> >>> mounts.
> >
> > *Blink*
> >
> > Let me reiterate what I think I am seeing.  The properties of a
> > propogated mount taking on attributes from the propagation node, where
> > the mount is propagated too.
> >
> > I honestly can't say if any code cares today, but this feels like it
> > will break the principle of least surprise and break someone.
> 
> Thinking about this a little I am almost certain this will break
> something.
> 
> A common pattern for containers is to have a read-only shared portion
> typically the rootfs and then other mounts that are read-write.  If all
> of your propagation nodes hang off of a big read-only mount (and
> therefore need to be read-only) forcing everything else to propagate
> into the container as read-only is likely going to break something.
> 
> > We can safely add this extension by adding a new flag or flags that can
> > be set on a pnode that will give the desired semantics.  So I expect
> > that is a better model then adding new semantics to MNT_RDONLY.
> 
> Which means I think to do this safely we really do need to add a new
> flag.

Yes. This can be made generic, independent of
propagation/shared-subtree semantics.

"Any mount that has been marked as 'propagate-access' will pass-on
its read-write attribute to its children."

'propagate-*' may confuse the reader
into thinking shared-subtree.  May be 'pass-on-access' or 'endow-access'
or 'inherit-to-access' :-).

Anyway; so something like this should be possible without breaking
existing semantics.

mount -o bind,remount,ro /mnt
mount --make-pass-on-access  /mnt

anything that gets mounted under /mnt will inherit the
'ro' attribute from its parent.  And when a mount-event propagates
to a read-only-slave-mount, that new mount will automatically 
inherit the read-only attribute from its slave-parent.

Dawid: will that work for you?
RP

Powered by blists - more mailing lists