Message-ID: <87y3o6eewq.fsf@xmission.com>
Date:   Thu, 19 Oct 2017 21:23:01 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Ram Pai <linuxram@...ibm.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?

Ram Pai <linuxram@...ibm.com> writes:

> 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@...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. :-(

My feel is that the read-write case should allow read-write only if the
incoming mount is read-write.  If the incomming write is read-only it
should stay read-only.  Meanwhile the sticky bit would connect to the
new read-only mount as sticky read-write.

*Thinks a minute*  That takes another bit and does not seem to add
anything so a sticky bit that just forces read-only makes sense.

>> >> 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?

Thinking.

A big part of the semantics that has not been described is how does
stickiness propagate.

My inclination would be to define stickiness this way:

a) We start with a single bit MNT_STICKY

b) stickiness propagates like any other mount attribute.
   AKA setting stickiness propgates everywhere and sets stickiness
       clearing stickiness propgates everywhere and clears stickiness

c) We add MNT_LOCK_STICKY to remember the stickiness came from a more
   privileged mount namespace.

d) If the sticky is on a read-only mount and all future child mounts
   (while the sticky remains) will be read-only and sticky

e) If the sticky is on a nodev mount all future child mounts (while the
   sticky remains) will be nodev and sticky

f) If the sticky is on a nosuid mount all future child mounts (while the
   sticky remains) will be nosuid and sticky

g) If the sticky is on a noexec mount all future child mounts (while the
   sticky remains) will be noexec and sticky.

h) A sufficiently privileged user may clear the sticky with no other
   effects than the clear of the sticky propgates.

i) A sufficiently privileged user may clear one of read-only, nodev,
   nosuid, or noexec under a sticky and it has no other effects except
   the change in mount flags propagtes like normal.

Or in short the sticky would just glom onto mount level disables and
make them the default.

Eric

Powered by blists - more mailing lists