Re: Read-only `slaves` with shared subtrees?

[Ram Pai <linuxram@us.ibm.com>]

On Mon, Oct 09, 2017 at 02:39:49PM -0700, Dawid Ciezarkiewicz wrote:
> On Sun, Oct 8, 2017 at 5:15 PM, Ram Pai <linuxram@us.ibm.com> wrote:
> >>
> >> One thing that I don't plan to use, but might be worth thinking about is
> >>  `slave + RW + STICKY` combination.  If `master` mounts something RO,
> >> and `slave`
> >> is `RW + STICKY`, should the mount appear RW inside the slave? I don't
> >> find it particularly useful,
> >> but still...
> >
> > As per the implemented semantics it will become "RW".  Should it be "RO"
> > aswell?  Will that open up security holes?
> 
> It is a mechanism that could be used to potentially increase the scope
> of privileges, which is a fertile ground for security issues. There is
> some room for using it to circumvent mechanisms that were unaware of
> this new feature. I guess for this reason alone, it might be worth
> limiting to RO only.l


ok. makes sense. It puts a twist to what I thought would have been
straight-forward-semantics. :-(

> 
> >>
> >> Another thing that popped into my head: Is it worth considering any
> >> dynamic changes to `slave`'s
> >> RO status? It complicates everything a lot (it seems to me), since it
> >> adds a retroactive
> >> dynamic propagation. I don't currently have any plans to use it, but I
> >> could imagine scenarios
> >> in which a slave mount with all it's sub-mounts is remounted from RO
> >> to RW, in response to
> >> some external authorization trigger.
> >
> > The sematics should be something like this. Check if it makes sense.
> >
> > a) anything mounted under stick-mount will be a sticky-mount and will
> >         inherit the mount's access-attribute;i.e RO RW attribute.
> > b) a mount when made sticky will propagate its sticky attribute
> >         as well as its access-attribute recursively to its children
> > c) anything mounted under non-sticky mount will not inherit the
> >         mount's access-attribute and will be non-sticky aswell.
> > d) a mount when made non-sticky will just change itself to non-sticky.
> >         (will NOT propagate its non-sticky attribute and its
> >         access-attribue recursively to its children.)
> 
> a), b) and c), seem uncontroversial. d) seems OK, but I'm unsure as it
> is asymmetrical to b). Both recursive and non-recursive D seem to make
> sense. I'm just unsure if any is more useful than the other.
> 
> What happens when a sticky RO slave mount is remounted as RW? Does it
> loose stickiness? Does this change propagate to its children?
> 
> Another angle, that just appeared to me: If we have a double link A
> (master) -> (slave) B (master) -> (slave) C
> 
> If A is RW and B is RO + sticky, does mount propagated to C will also
> be RO? It seems to me it should.

that seems to be the right thing to do.  

Do you want to code up something and send? I can aswell.. but bit
occupied with other high-priority stuff.

@Eric:  Any thoughts on the proposed semantics? 

RP