From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:47950 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751795AbdIUAjh (ORCPT ); Wed, 20 Sep 2017 20:39:37 -0400 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8L0dKDJ114067 for ; Wed, 20 Sep 2017 20:39:36 -0400 Received: from e19.ny.us.ibm.com (e19.ny.us.ibm.com [129.33.205.209]) by mx0b-001b2d01.pphosted.com with ESMTP id 2d3ywrrqb5-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Sep 2017 20:39:35 -0400 Received: from localhost by e19.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Sep 2017 20:39:35 -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> Message-Id: <20170921003930.GM5698@ram.oc3035372033.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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