Date:   Tue, 5 May 2020 13:31:28 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Dave Chinner <david@...morbit.com>
Cc:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        Jan Kara <jack@...e.cz>, Francois <rigault.francois@...il.com>,
        Wang Shilong <wangshilong1991@...il.com>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: ext4 and project quotas bugs

On May 4, 2020, at 6:32 PM, Dave Chinner <david@...morbit.com> wrote:
> 
> On Wed, Apr 29, 2020 at 08:01:32AM -0700, Darrick J. Wong wrote:
>> On Tue, Apr 28, 2020 at 09:34:09PM -0600, Andreas Dilger wrote:
>>> 
>>> We tried to implement (restricted project IDs) for ext4, but
>>> Dave Chinner argued that allowing anyone (at least in the root
>>> namespace) to set the project ID to anything they wanted was
>>> part of how project quotas are _supposed_ to work.
>>> 
>>> We ended up adding a restriction at the Lustre level, defaulting to
>>> only allow root (chprojid_gid=0, via CAP_SYS_RESOURCE), or admins in
>>> a specific numeric group (with chprojid_gid=N), to change the projid,
>>> and denying regular users the ability to change the projid of files.
>>> 
>>> This can be changed by setting "chprojid_gid=-1" to allow users in
>>> any group to change the projid of files, returning the XFS behavior.
>>> The "chprojid_gid" is essentially a sysfs tunable for Lustre, but it
>>> could also/instead be a mount option for ext4, if that is preferred.
>>> I don't have a particular attachment to the parameter name, or how
>>> it is set by the admin, but I think something like this is needed.
>>> 
>>> 
>>>>> 2- project quota are a bit too easy to escape:
>>>>> dd if=/dev/zero of=someoutput oflag=append
>>>>> loop0: write failed, project block limit reached.
>>>>> dd: writing to 'someoutput': Disk quota exceeded
>>>>> 2467+0 records in
>>>>> 2466+0 records out
>>>>> 1262592 bytes (1.3 MB, 1.2 MiB) copied, 0.0105432 s, 120 MB/s
>>>>> vagrant@...alhost:/mnt/loop/abc/mydir3> chattr -p 33 someoutput
>>>>> vagrant@...alhost:/mnt/loop/abc/mydir3> dd if=/dev/zero of=someoutput
>>>>> oflag=append
>>>>> dd: writing to 'someoutput': No space left on device
>>>>> 127393+0 records in
>>>>> 127392+0 records out
>>>>> 65224704 bytes (65 MB, 62 MiB) copied, 0.568859 s, 115 MB/s
>>>> 
>>>> Yes and as I mentioned above this is deliberate.
>>> 
>>> That may be the historical XFS behavior, but IMHO, it doesn't make
>>> this behavior *useful*.  If *anyone* can change the projid of files
>>> that makes them mostly useless.  They might be OK for informational
>>> or accounting purposes (e.g. fast "du" of a directory) in a friendly
>>> user environment, but they are useless for any space management (i.e.
>>> anyone can easily bypass project limits by "chattr -p $RANDOM <file>").
>>> 
>>> I'd prefer to make the project quotas useful out of the box for ext4,
>>> by implementing the chprojid_gid tunable, or something equivalent.
>>> If there are users/sites that want identical behavior to XFS, they
>>> can always set chprojid_gid=-1 to allow anyone to change the projid.
>>> 
>>> I'd be happy to understand what Dave doesn't like about this proposal,
>>> but the last time the enforcement of project quotas was discussed, my
>>> attempt to figure this out ended with silence, see thread ending at:
>>> 
>>> https://lore.kernel.org/linux-ext4/6B0D1F84-0718-4E43-87D4-C8AFC94C0163@dilger.ca/
>>> 
>>> Maybe this time we can get over the hump?  Is it just some implicit
>>> difference between "directory quota" and "project quota" that exists
>>> in XFS that I (and everyone using ext4) does not understand?
>> 
>> I don't have any particular objection to adding an admin-controlled
>> means to restrict who can change project ids on a file, other than let's
>> do this in a consistent way for the three fses that support prjquota.
> 
> That's my stance in a nutshell. Project quotas are not a "ext4 can
> do whatever they like and screw everyone else" feature.

My intent has *never* been "screw everyone else", and I don't see how
you can read that into "I'd be happy to understand what Dave doesn't
like about this proposal, but the last time the enforcement of project
quotas was discussed, my attempt to figure this out ended with silence."

I'm not trying to introduce gratuitous differences to project quotas,
but you shot down the previous proposal to prevent regular users from
arbitrarily changing project IDs as "a horrible 'designed by an engineer
to meet a specific requirement' interface" without offering a useful
alternative in return.  Maybe I misunderstood and you were describing
the current XFS project ID behavior of allowing users to change the
project ID to anything they want, your comment wasn't specific? :-)

Clearly there is a need to be able to prevent users from changing the
projid of files, as it's come up a number of times already.

> New features for project quotas *must* be consistently managed and
> provide -exactly the same semantics- across all filesystems that
> support project quotas. That means new management features is *must*
> be supportable by all filesystems and implemented *in the same
> patchset* for all filesystems that support project quotas.
> 
> Fragmenting the functionality space because "ext4 does not play well
> with others" is not acceptible anymore. If you implement
> functionality that other filesystems support and then want to extend
> it, you need to bring all the other filesystems along with ext4.

The original proposal was never "let's change ext4 project quotas to
be fundamentally different from XFS", but rather "here's an *option*
to fix what several users have reported as an issue with project quota
behavior (being able to change the projid arbitrarily), with the
ability to revert to the existing project quota behavior that XFS
has for archaic reasons, if needed".

>> Personally, I thought Dave was stating how we got to the current
>> prjquota implementation w/ non-entirely-intuitive Irix behavior and then
>> asked for a concrete definition of new behavior + patches and was
>> waiting to see if Wang or someone would send out f2fs/ext4/xfs patches...
> 
> Yup, that's pretty much it.

The intent of the previous thread, and this one as well, is that it seems
the ext4 developers *don't understand* the Irix/XFS semantics of project
quotas vs. directory quotas, and I was asking for clarification on what
the difference between "project quotas" and "directory quotas" as exists
n XFS today (if there is a difference)?

Is it "directory quotas have PROJID_INHERIT", and "project quotas do not",
but this has nothing to do with quota *enforcement* (which is nonexistent)?

Do files created in directories with a project ID set, but *not* having
PROJID_INHERIT, still inherit the projid, but this isn't enforced?  That
doesn't seem to be the case.

Is it that files and subdirectories in directories with PROJID_INHERIT set
can only be changed by the root user in the init namespace, but if the
parent does not have PROJID_INHERIT set then users in the init namespace
can change the projid of any file that they can write?  That also doesn't
seem to be the case.

I ran some tests on XFS and couldn't see any way to prevent a regular
user from changing the projid arbitrarily with chattr, so it doesn't
*appear* to be a quirk with how project quotas is implemented by ext4.
Is there some mechanism/option/xfs_quota magic that *prevents* users from
changing the projid that I'm missing?

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)

Powered by blists - more mailing lists