From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753674AbdJIAP4 (ORCPT ); Sun, 8 Oct 2017 20:15:56 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52314 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751263AbdJIAPy (ORCPT ); Sun, 8 Oct 2017 20:15:54 -0400 Date: Sun, 8 Oct 2017 19:15:46 -0500 From: Ram Pai To: Dawid Ciezarkiewicz Cc: "Eric W. Biederman" , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: Read-only `slaves` with shared subtrees? Reply-To: Ram Pai References: <20170920193954.GK5698@ram.oc3035372033.ibm.com> <20170920194108.GB5721@ram.oc3035372033.ibm.com> <87377h2d4a.fsf@xmission.com> <87shfh0y28.fsf@xmission.com> <20170921003930.GM5698@ram.oc3035372033.ibm.com> <20170921191434.GP5698@ram.oc3035372033.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17100900-0052-0000-0000-0000026E5BE6 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007864; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000235; SDB=6.00928393; UDB=6.00467216; IPR=6.00708665; BA=6.00005626; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017452; XFM=3.00000015; UTC=2017-10-09 00:15:51 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17100900-0053-0000-0000-00005240A933 Message-Id: <20171009001546.GB5675@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-08_05:,, 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-1710090002 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 29, 2017 at 04:02:42PM -0700, Dawid Ciezarkiewicz wrote: > On Fri, Sep 22, 2017 at 11:43 AM, Dawid Ciezarkiewicz > wrote: > > On Thu, Sep 21, 2017 at 12:14 PM, Ram Pai 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. yes it will be RO. the patch takes care of that. > > 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? > > 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.) Will this work? > Regards, > Dawid Ciezarkiewicz -- Ram Pai