I was trying to figure out why /usr/bin/quota reports group quotas for the caller's supplementary groups, and not for the caller's real group ID (if that isn't one of the supplementary groups.)
"quota -g" only looks at getgroups() and ignores the real GID. By itself this is a minor issue, since you can use "quota -g $(id -g)" instead.
But, if the real GID isn't one of the supplementary groups, then "quota -g $(id -g)" says "Permission denied". This is misleading - the kernel doesn't deny permission; 'quota' itself refuses to do what is asked.
This is because the "BSD_BEHAVIOUR" permission checks (quotaops.c, lines 76-124) don't take the real or effective GID into account.
But that just raises the larger question - what is "BSD_BEHAVIOUR" for? Why is this enabled by default (configure.ac, lines 263-271)? The quotactl() system call on Linux has its own permission checks; it doesn't make sense for userspace to try to second-guess the kernel's permissions. 'quota' isn't a privileged executable; anybody can compile their own version with the "BSD_BEHAVIOUR" checks removed.
In investigating this, I also noticed that in the case of XFS, 'quota' ignores any error returned by quotactl() (quotaio_xfs.c, line 179), and prints out a list of all zeroes instead.
In investigating that, I also noticed that the XFS quotactl() call fails with ENOENT if the specified GID owns no files and has no limits. So in the ENOENT case, printing out a list of all zeroes is appropriate.
(In contrast, XFS quotactl() fails with EPERM if permission is denied, ESRCH if group quota accounting is disabled, or ENOSYS if all quota accounting is disabled.)
In conclusion:
Anonymous
Thanks for the detailed report! Indeed all good points, I'm particularly puzzled how the bug in xfs_read_dquot() got there. Apparently it is there over 23 years since the initial XFS support written by SGI guys back then :)
Problems fixed and a few more I've found on top when testing this :)