Re: ext4 and project quotas bugs

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Tue, Apr 28, 2020 at 09:34:09PM -0600, Andreas Dilger wrote:
> On Apr 28, 2020, at 9:32 AM, Jan Kara <jack@suse.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@localhost:/mnt/loop/abc/mydir3> chattr -p 33 someoutput
> >> vagrant@localhost:/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.

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...

--D

> 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.
> 
> 
>