From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752129AbdIUAjl (ORCPT ); Wed, 20 Sep 2017 20:39:41 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:51080 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751652AbdIUAjh (ORCPT ); Wed, 20 Sep 2017 20:39:37 -0400 Date: Wed, 20 Sep 2017 17:39:30 -0700 From: Ram Pai To: "Eric W. Biederman" Cc: Dawid Ciezarkiewicz , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: Read-only `slaves` with shared subtrees? Reply-To: Ram Pai References: <20170918204710.GI5698@ram.oc3035372033.ibm.com> <20170920193954.GK5698@ram.oc3035372033.ibm.com> <20170920194108.GB5721@ram.oc3035372033.ibm.com> <87377h2d4a.fsf@xmission.com> <87shfh0y28.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87shfh0y28.fsf@xmission.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17092100-0056-0000-0000-000003CC662D X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007770; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000230; SDB=6.00919987; UDB=6.00462243; IPR=6.00700214; BA=6.00005599; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017227; XFM=3.00000015; UTC=2017-09-21 00:39:34 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17092100-0057-0000-0000-000008036AB3 Message-Id: <20170921003930.GM5698@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-20_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709210007 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 20, 2017 at 06:06:55PM -0500, Eric W. Biederman wrote: > ebiederm@xmission.com (Eric W. Biederman) writes: > > > Ram Pai 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 wrote: > >>> > > It is possible to make a slave mount readonly, by remounting it with > >>> > > 'ro' flags. > >>> > > > >>> > > something like > >>> > > > >>> > > mount -o bind,remount,ro > >>> > > > >>> > > 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