On Wed, Sep 20, 2017 at 06:06:55PM -0500, Eric W. Biederman wrote: > ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > > > Ram Pai <linuxram@xxxxxxxxxx> 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@xxxxxxxxxx> 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
