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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOEu9U5c3dWBPdAWb_TduoPv78fT0JLkZCjSYvpY37QHjkr1FA@mail.gmail.com>
Date:   Fri, 29 Sep 2017 16:02:42 -0700
From:   Dawid Ciezarkiewicz <dawid.ciezarkiewicz@...rik.com>
To:     Ram Pai <linuxram@...ibm.com>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: Read-only `slaves` with shared subtrees?

On Fri, Sep 22, 2017 at 11:43 AM, Dawid Ciezarkiewicz
<dawid.ciezarkiewicz@...rik.com> wrote:
> On Thu, Sep 21, 2017 at 12:14 PM, Ram Pai <linuxram@...ibm.com> wrote:
>> Here is a patch that accomplishes the job. tested to work with
>> some simple use cases.  check if this works for you. If it does
>> than we will have to think through all the edge cases and make it
>> acceptable.
>
> From your experiments, it looks exactly right.
>
> I'll give it a try in the upcoming week. Thank you!

I've reproduced your setup and results.

I've played with it for a while, mostly checking some recursive mount scenarios.
My biggest concern is transitivity of the RO attribute. Once a root of
slave directory
is set to be RO + STICKY, it is very important that host directories
propagated there,
even recursively (rslave), or any other, are not RW. From what I was
able to test, everything
seemed OK, but I don't grok all the semantics around it, so I'm just
pointing it out, as I might
have missed something.

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

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.

Regards,
Dawid Ciezarkiewicz