Date:   Tue, 28 Apr 2020 21:34:09 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Jan Kara <jack@...e.cz>
Cc:     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 Apr 28, 2020, at 9:32 AM, Jan Kara <jack@...e.cz> wrote:
> 
> Hello!
> 
> On Tue 28-04-20 08:41:59, Francois wrote:
>> my goal is to make some kind of ansible playbook to install project
>> quotas, so I am interested in using a tool like setquota, I also want
>> the teams behind the capped directories, to think about a clean-up
>> mechanism (the quota would just be a temporary annoyance for them), so
>> it should not be "jailbreakable" too easily.
> 
> Hum, that "not jailbreakable" part is going to be difficult unless you also
> confine those users also in their user namespace. Because any user is
> allowed to change project ID of the files he owns arbitrarily if he is
> running in the initial user namespace. Project quotas have been designed as
> an advisory feature back in Irix days... There are talks of allowing to
> tweak the behavior (i.e., to allow setting of project id only by sysadmin)
> by a mount option but so far nobody has implemented it.

We tried to implement this 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?

Cheers, Andreas


PS: Implementing /etc/projid support for e2fsprogs chattr/lsattr to
allow project names would also be useful, but IMHO less important.
That would be a relatively easy feature for someone to implement,
since it only involves userspace and is unlikely to get objections.




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

Powered by blists - more mailing lists