From: cem@kernel.org
To: zlang@kernel.org
Cc: djwong@kernel.org, hch@lst.de, linux-xfs@vger.kernel.org,
fstests@vger.kernel.org, jack@suse.cz
Subject: [RFC PATCH 0/2] quota evasion test and nfs helpers
Date: Mon, 7 Sep 2026 18:40:46 +0200 [thread overview]
Message-ID: <20260907164054.111393-1-cem@kernel.org> (raw)
From: Carlos Maiolino <cem@kernel.org>
Hi folks.
I'm flagging these as RFC because I'd like an input in the approach I
took here regarding how to setup a local nfs-server to reproduce the bug
recently fixed on xfs quotas.
The issue is regarding how we checked the credentials before proceeding
with quota enforcement / or not. And due the chgrp() being run through a
NSF share, xfs used the wrong credentials allowing an user to evade
quotas.
The TL;DR; for the approach is:
- setup a xfs fs with an user belonging to two groups with group
quotas enforced
- Setup a local nfs server/client and mount it locally through
loopback
- use the user to fill in the share until it exceeds quota
- change group of the file to the second group.
- repeat a couple times until the second group quota is
exceeded.
I'm using the already existing user/groups. The tests uses exportfs directly
instead of seeting up a exports file, and I added a few new helpers to
start/stop nfsd and rpcbind. The latter I did as an attempt to make the test
systemd-agnostic. It is working even if nfs-server systemd service is disabled,
but I didn't try on a systemd-less OS.
While writing it I stumped on a weird issue that I'm not exactly sure
how to fix (or if it's perhaps a bug on umount):
During cleanup(), I umount the share and unexport the it so the rest
of the generic cleanup can take place, specially umounting the scratch
fs There is some timing though required by umount() to properly cleanup
internal kernel structures before it can be unexported. I honestly
assumed umount() was synchronous (unless lazy umount) and once it returned
it was "done". But for some reason I didn't dig into, I need to wait a
bit between unmounting the share and unexporting it.
I tried to wait until the mount was excluded from /proc/mounts but even
after the mount is gone, something still holds the share a bit
preventing it to be unexported. So I went with a 2 second sleep :)
Overall the test works, passing on a patched kernel or failing
otherwise.
Comments? Flames? Stones?
Cheers.
Carlos Maiolino (2):
common/nfs: add management helpers
generic: add test for quota enforcement via a nfs share
common/nfs | 55 ++++++++++++++++++++++
tests/generic/803 | 106 ++++++++++++++++++++++++++++++++++++++++++
tests/generic/803.out | 2 +
3 files changed, 163 insertions(+)
create mode 100755 tests/generic/803
create mode 100644 tests/generic/803.out
--
2.55.0
next reply other threads:[~2026-09-07 16:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 16:40 cem [this message]
2026-09-07 16:40 ` [RFC PATCH 1/2] common/nfs: add management helpers cem
2026-09-08 14:22 ` Darrick J. Wong
2026-09-09 6:12 ` Christoph Hellwig
2026-09-09 16:13 ` Darrick J. Wong
2026-09-10 9:45 ` Carlos Maiolino
2026-09-10 11:30 ` Jeff Layton
2026-09-10 11:40 ` Carlos Maiolino
2026-09-10 11:48 ` Jeff Layton
2026-09-07 16:40 ` [RFC PATCH 2/2] generic: add test for quota enforcement via a nfs share cem
2026-09-08 10:25 ` Jan Kara
2026-09-08 10:29 ` [RFC PATCH 0/2] quota evasion test and nfs helpers Jan Kara
2026-09-10 11:34 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260907164054.111393-1-cem@kernel.org \
--to=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).