linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <CAOEu9U6WWH+ekbRTQOi=BfvtV+DiPXTKf3+aKbQ7Rz04VKZr-g@mail.gmail.com>
Date:   Fri, 15 Sep 2017 10:57:30 -0700
From:   Dawid Ciezarkiewicz <dawid.ciezarkiewicz@...rik.com>
To:     linux-kernel@...r.kernel.org
Cc:     Dawid Ciezarkiewicz <dawid.ciezarkiewicz@...rik.com>,
        linuxram@...ibm.com
Subject: Read-only `slaves` with shared subtrees?

Hi,

(Please keep me in CC me when responding.)

I have an use-case for shared subtrees that is not covered by:

https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt

and I wasn't able to figure out any working solution - it might not be possible
ATM.

Long story short:
I'd like the `slave` mount (service in a container) to mount propagated events
as RO, no matter how did `master` (host) mount them. Host might need that data
RW, but slave must have it RO only.

I'm using Linux containers to isolate processes. I need the container
to follow part of the host system mount tree, but not have a write-access to it
(for security reasons). It's a trivial setup as long
as everything is static, but as soon as a part of what the container needs
to access is mounted/unmounted at runtime (and thus shared subtrees
are involved),
there seems to be no way to control the flags of the propagated mount events.

I might be able to write a patch implementing this, but before attempting that,
I'd like to confirm:

* Is it even a good idea?
* Is it maybe already possible by some other means?
* Is it an use-case that might potentially be worth supporting in the mainline?
   If so: any hints/ideas about the design and API?

Best Regards,
--
Dawid Ciezarkiewicz
Software Engineer at Rubrik