From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753797AbdJSSNK (ORCPT ); Thu, 19 Oct 2017 14:13:10 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36152 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753738AbdJSSNI (ORCPT ); Thu, 19 Oct 2017 14:13:08 -0400 Date: Thu, 19 Oct 2017 11:13:00 -0700 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: <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> <20171009001546.GB5675@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: 17101918-0040-0000-0000-000003B53ECE X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007919; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000238; SDB=6.00933483; UDB=6.00470186; IPR=6.00713772; BA=6.00005651; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017610; XFM=3.00000015; UTC=2017-10-19 18:13:05 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17101918-0041-0000-0000-000007AA470A Message-Id: <20171019181300.GY5617@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-19_09:,, 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-1710190250 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 09, 2017 at 02:39:49PM -0700, Dawid Ciezarkiewicz wrote: > On Sun, Oct 8, 2017 at 5:15 PM, Ram Pai wrote: > >> > >> 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? > > It is a mechanism that could be used to potentially increase the scope > of privileges, which is a fertile ground for security issues. There is > some room for using it to circumvent mechanisms that were unaware of > this new feature. I guess for this reason alone, it might be worth > limiting to RO only.l ok. makes sense. It puts a twist to what I thought would have been straight-forward-semantics. :-( > > >> > >> 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.) > > a), b) and c), seem uncontroversial. d) seems OK, but I'm unsure as it > is asymmetrical to b). Both recursive and non-recursive D seem to make > sense. I'm just unsure if any is more useful than the other. > > What happens when a sticky RO slave mount is remounted as RW? Does it > loose stickiness? Does this change propagate to its children? > > Another angle, that just appeared to me: If we have a double link A > (master) -> (slave) B (master) -> (slave) C > > If A is RW and B is RO + sticky, does mount propagated to C will also > be RO? It seems to me it should. that seems to be the right thing to do. Do you want to code up something and send? I can aswell.. but bit occupied with other high-priority stuff. @Eric: Any thoughts on the proposed semantics? RP