[LU-8598] flaw in the ldiskfs group quota enforcement

• Type: Bug
• Resolution: Duplicate
• Priority: Minor
• Affects Version/s: Lustre 2.5.3
• Environment: Lustre 2.5.3.90 w/ Bull patches, ldiskfs backend

Epic/Theme

Quota

• Severity: 3
• Assignee: Niu Yawei (Inactive)
• Reporter: Bruno Travouillon (Inactive)

Description

A user found out that the Lustre group quota enforcement can be overwhelmed
under particular circumstances.

Here is an example provided by our customer. On their system a user is a member
of group matlab. Group matlab is a group intended to give access to a licensed
application, but it is not supposed to give access to any additional project
storage resources. On any Unix or Linux system, it is allowed to that users,
owners of a file, can change the group of their files to any other group they
are a member of. So to prevent that group matlab, and similar groups, are
abused for gaining access to additional storage resources, they set the limits
for such groups as low as possible – i.e. to 1, since 0 actually means
“unlimited”.

The example below shows how easily the limits can be circumvented when new
files are created with a group GID that is not over quota yet, and then
immediately changed to another group. The output of the lfs quota command at
the end demonstrates that Lustre knowns about the exceeded limit, but does not
stop or enforce anything at all.

cli1$ lfs quota -g matlab /scratch
Disk quotas for group matlab (gid 1000):
     Filesystem  kbytes   quota   limit   grace   files   quota   limit   grace
       /scratch       0       0       0       -       1*      1       1       -
cli1$ 
cli1$ 
cli1$ for i in {0..4999}; do touch file.$i && chgrp matlab file.$i; done
cli1$ lfs quota -g matlab /scratch
Disk quotas for group matlab (gid 1000):
     Filesystem  kbytes   quota   limit   grace   files   quota   limit   grace
       /scratch       0       0       0       -    5001*      1       1       -

This issue is easily reproducible. By looking at the debug log, the quota code
in Lustre returns -EDQUOT, but the chgrp operation is allowed anyway.

The defect is in osd_declare_attr_set() where rc is changed to 0 if (rc ==
-EDQUOT || rc == -EINPROGRESS).

We can find the following comment in the code:

/* Changing ownership is always preformed by super user, it should not
* fail with EDQUOT.

While this is true for the user ownership, this is not for the group ownership.

A similar issue is already described in LU-5152.

Issue Links

• duplicates: LU-5152 Can't enforce block quota when unprivileged user change group