Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp334436img; Mon, 18 Mar 2019 04:20:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqxkovoK2rs6y/ffaPBl+sK1JO9cqripStW4W1T1Xe80XXjiwlcVORNVzNp9j2ZtoYCnXhqE X-Received: by 2002:a17:902:28e6:: with SMTP id f93mr19568726plb.264.1552908049358; Mon, 18 Mar 2019 04:20:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552908049; cv=none; d=google.com; s=arc-20160816; b=LsPuEput637YQumQryBy3/t4g+yrcEo/s7jxsyc/d3Ss2UjiBQio2VgQCRAn466Sa5 FwuWz7hKwdteu8pdfxvcPT2HdMD7KKlyG1kizdabBhj3/qtfrG5GHqsWZk1f1v0+uOoF f4aZmtyX8Bu4UtXUPTItm/XyjWGxxCHbsMdQXytLBfdpDa++1f66ocKpiQKRYkByFdAF sNqbdDkyAsg8kYLKSpx+z1ChOnZblzZsaL1BdrsnyfeGo2jTb++iAEZsteTootjorzeg XigpihYXhzsuv8PDYwiDUNptEwluYwcK74Z3WXYXt6r0fkvmFVz+qWkAkBofMGUV6vNy ksiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=LuMUJQAaY87/HXNfGHrFFRQkIhHekKIC4vvffzsFHoY=; b=iNxHIvwZ5AwHR04irf7yPFGqBlsEwgZai0VDU8/ObMiljKjLDmYUKgeKE+tWXAfMgA fAMUZzFjEEdQucKDKPWvqoJ2mbaDhoPV8rJ39OsEWg/JtIa6vSXcXP9gjPlZBEOUR8PC k0hAcd624+L0KaWzFGkuKzSCdfMMIuHn6SqKD2sNX+7jX81p/XAo0iH1IPx6F5H9X+4t cuVhcRxM93HY2PimsSqQvlhog93L4fdmKzGUB3FQ+OW3l7f/pfymKkLBmj5kalyzHTsB LIO889FVd9M4tOQbnDExxDdf227LcZcEPVCKpxooKE0HqotEEtaMMSto9wSUSqBmZrOD tw8w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e6si9103369pfc.201.2019.03.18.04.20.34; Mon, 18 Mar 2019 04:20:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726844AbfCRLTx (ORCPT + 99 others); Mon, 18 Mar 2019 07:19:53 -0400 Received: from mail-lf1-f68.google.com ([209.85.167.68]:40065 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726493AbfCRLTx (ORCPT ); Mon, 18 Mar 2019 07:19:53 -0400 Received: by mail-lf1-f68.google.com with SMTP id u68so11387885lff.7 for ; Mon, 18 Mar 2019 04:19:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LuMUJQAaY87/HXNfGHrFFRQkIhHekKIC4vvffzsFHoY=; b=d/fLHmoxVIYWTpmbK26DRsIJXcOGEDGccBsxlV/b7+OKCcsGyWIwPPw3Dh89Mw7cjn wXCqfeIUb94LXskDkJU1v2Wzqk/+d1ImMwlvowvcMyE/pJVqplwD2ePB0zwFYabvt9q/ iHOGhN+n+t95Rd/r8bIFZ5kitrDmM3MkMstdXA+JD7d0m4HJDl0Vkeq00fUKQs0r1XUN KHj+fM0hXvwOg8ffqy9fbQNRW7pVZ3CVH+NYem4JjGnpWlqC/isT9yzbfnoMLQu8ZWB+ 7SFQKVF4+vx5eMxlXCPRGHszI9vOupAlRmYse5FwcfA/sx3L3PupihNAH3yaOU76Yquz abSw== X-Gm-Message-State: APjAAAUUS2ryWORMMeU/giILSeKS8YMWqKRq8RX6q6v7ADr+29+LwVyP 1RciJT0hhqaecSBPT8n/GCyzCF7nrmGrNLU6GO3ZZw== X-Received: by 2002:a19:6a0b:: with SMTP id u11mr9931675lfu.13.1552907991300; Mon, 18 Mar 2019 04:19:51 -0700 (PDT) MIME-Version: 1.0 References: <20190312142019.30936-1-lhenriques@suse.com> <20190312142019.30936-3-lhenriques@suse.com> <87lg1czc26.fsf@suse.com> In-Reply-To: <87lg1czc26.fsf@suse.com> From: Gregory Farnum Date: Mon, 18 Mar 2019 16:49:40 +0530 Message-ID: Subject: Re: [PATCH v2 2/2] ceph: quota: fix quota subdir mounts To: Luis Henriques Cc: "Yan, Zheng" , "Yan, Zheng" , Sage Weil , Ilya Dryomov , ceph-devel , Linux Kernel Mailing List , Hendrik Peyerl Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 18, 2019 at 4:25 PM Luis Henriques wrote: > > "Yan, Zheng" writes: > > > On Mon, Mar 18, 2019 at 5:06 PM Gregory Farnum wrote: > >> > >> On Mon, Mar 18, 2019 at 2:32 PM Yan, Zheng wrote: > >> > After reading the code carefully. I feel a little uncomfortable with > >> > the "lookup_ino" in get_quota_realm. how about populating directories > >> > above the 'mount subdir' during mounting (similar to cifs_get_root ). > > Wouldn't it be a problem if the directory layout (or, in this case, the > snaprealm layout) change during the mount lifetime? In that case we > would need to do this lookup anyway. > > >> > >> Isn't that going to be a problem for any clients which have > >>restricted filesystem access permissions? They may not be able to see > >>all the directories above their mount point. -Greg > > > > using lookup_ino to get inode above the "mount subdir" has the same problem > > > > In this case I believe we get an -EPERM from the MDS. And then the > client simply falls back to the 'default' behaviour, which is to allow > the user to create/write to files as if there were no quotas set. Right, but a client is a lot more likely to have access to /home// than they are to also be able to look at /, and /home. So if they can do a lookup on /home// they get their quota, but if they have to look it up from the root it's lost even though the client has permission to see all the things that contain their quota state... :/ > > Cheers, > -- > Luis