On Apr 28, 2020, at 9:32 AM, Jan Kara <jack@xxxxxxx> 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@xxxxxxxxx/ 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.
Attachment:
signature.asc
Description: Message signed with OpenPGP
