Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp882724ybg; Fri, 18 Oct 2019 08:45:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqzpTZ4IL3ekinwE6tnv074Zcbg7KkdOR974m4gSuYNfyPvalrNa3ZEESR3r8kVGtzUOVf2J X-Received: by 2002:aa7:df86:: with SMTP id b6mr10240817edy.107.1571413515338; Fri, 18 Oct 2019 08:45:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571413515; cv=none; d=google.com; s=arc-20160816; b=jqE7SzAmSy1T5Vigpa1PECW4DL5kJbYKbgWTVGdOV/67Q5tNrBQ3Jlyeb2gucFXYUe 5/XG2ygcM88s+xcyRVH+twEuxJvrNM/Trzpxq/6e4NdMyp+N0Y3eA6cif+hT+mMiSa1r I9g7Jq0AuYsMuP1kayIy1sT3Bimv96vHMCCIxfpcOBzI9eHFhj1pGuCbjlKHoB6ERXrN gl+En2sFosJ3xF/A0UlNYPJHW/jG30RFLWO9gRVNi0uvVBK2fyuNFx8uvFLG6dDkurdL 82JZfEDApSrL7bM42/3qadMer3KQcTO6Q5r855N3E7Mz1stlLW6/y9GHLypT0wMI10VJ qgcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=b/yH17vHegP80kXD8oeU8LSCvbPLlBN9SQCVSDKHcEA=; b=Vp3mQW5SrbWBgZmnjQ/rR1+azs4lB7tyMvj2X8mCAJg4MgOYnudtV+hxNsiG0pUfsA WE32KdRZsyuDJLGvKgtwC7EClxGRmOKvh4QcppOoaf/Iq0NqM0mA9cUoDvI//2cItisN nsBjTGmh4l2VfqFbVPWNTImLxFk8J89YmozQrHj7sSkNxn5v9T7vilLVfzjfIvzYA2sg IQaQFobex9Kj0yI3AbY+PLasLMVYjCmKN6cdRaJ5isBMWFe61E6pxTUtInti17ncLd4t l3ucpSvnVncaBoDNt0GZRwQHV4XvX5vOXTntsMMvCSvsIS6Rf3QjbU1iIXatedpLqVPJ 2wrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w19si3712399eju.407.2019.10.18.08.44.49; Fri, 18 Oct 2019 08:45:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393190AbfJQMNC (ORCPT + 99 others); Thu, 17 Oct 2019 08:13:02 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:55323 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731634AbfJQMNC (ORCPT ); Thu, 17 Oct 2019 08:13:02 -0400 Received: from callcc.thunk.org (guestnat-104-133-0-98.corp.google.com [104.133.0.98] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9HCCqag024199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Oct 2019 08:12:53 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 13A9E420458; Thu, 17 Oct 2019 08:12:52 -0400 (EDT) Date: Thu, 17 Oct 2019 08:12:52 -0400 From: "Theodore Y. Ts'o" To: Andreas Dilger Cc: "Darrick J. Wong" , Wang Shilong , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, Ext4 Developers List , Li Xi , Wang Shilong Subject: Re: [Project Quota]file owner could change its project ID? Message-ID: <20191017121251.GB25548@mit.edu> References: <20191013164124.GR13108@magnolia> <20191016213700.GH13108@magnolia> <648712FB-0ECE-41F4-B6B8-98BD3168B2A4@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <648712FB-0ECE-41F4-B6B8-98BD3168B2A4@dilger.ca> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Oct 16, 2019 at 06:28:08PM -0600, Andreas Dilger wrote: > I don't think that this is really "directory quotas" in the end, since it > isn't changing the semantics that the same projid could exist in multiple > directory trees. The real difference is the ability to enforce existing > project quota limits for regular users outside of a container. Basically, > it is the same as regular users not being able to change the UID of their > files to dump quota to some other user. > > So rather than rename this "dirquota", it would be better to have a > an option like "projid_enforce" or "projid_restrict", or maybe some > more flexibility to allow only users in specific groups to change the > projid like "projid_admin=" so that e.g. "staff" or "admin" groups > can still change it (in addition to root) but not regular users. To > restrict it to root only, leave "projid_admin=0" and the default (to > keep the same "everyone can change projid" behavior) would be -1? I'm not sure how common the need for restsrictive quota enforcement is really going to be. Can someone convince me this is actually going to be a common use case? We could also solve the problem by adding an LSM hook called when there is an attempt to set the project ID, and for people who really want this, they can create a stackable LSM which enforces whatever behavior they want. If we think this going to be an speciality request, this might be the better way to go. - Ted