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

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.5.3
• Type: Bug
• Priority: Minor
• Reporter: Bruno Travouillon (Inactive)
• Assignee: Niu Yawei (Inactive)
• Resolution: Duplicate

Environment

Lustre 2.5.3.90 w/ Bull patches, ldiskfs backend

• Epic/Theme: Quota
• Severity: 3

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

Comments

[Peter Jones]

Niu

Could you please advise with this issue?

Thanks

Peter

[Gerrit Updater]

Bruno Travouillon ([e-mail]) uploaded a new patch: http://review.whamcloud.com/22421
Subject: LU-8598 osd-ldiskfs: enforce group quota while chgrp
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 33ddd52a0a9212bdd9f1c3ceba3fbd844ee495f6

[Niu Yawei (Inactive)]

This isn't a ldiskfs specific issue, it's Lustre quota issue. To fix the group inode quota is relative easy, while fixing the group block quota requires much more work (which is described in LU-5152).

[Bruno Travouillon (Inactive)]

Indeed, I started to work on another patch for osd-zfs when http://review.whamcloud.com/22421 failed sanity-quota check.