On Tue, Apr 28, 2020 at 09:34:09PM -0600, Andreas Dilger wrote: > 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? 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. > > >
