lkml.org 
[lkml]   [2017]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Read-only `slaves` with shared subtrees?
On Wed, Sep 20, 2017 at 06:06:55PM -0500, Eric W. Biederman wrote:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
> > Ram Pai <linuxram@us.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@us.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

\
 
 \ /
  Last update: 2017-09-21 19:26    [W:0.094 / U:9.896 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site