From: "Theodore Tso" <tytso@mit.edu>
To: Claudio Fernando Pinto <claudiofernandopinto@gmail.com>
Cc: linux-unionfs@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
Amir Goldstein <amir73il@gmail.com>,
linux-ext4@vger.kernel.org
Subject: Re: overlayfs: unprivileged writes can use ext4's reserved blocks with the default resuid
Date: Mon, 19 Oct 2026 23:54:18 -0400 [thread overview]
Message-ID: <atbfAjLsKxhkqW-q@mit.edu> (raw)
In-Reply-To: <CACs2WyyyGBxznvnJRDYWziAbzz8QROr41CF9Wtu9fOj7jX1fDw@mail.gmail.com>
On Mon, Oct 19, 2026 at 06:03:17AM -0500, Claudio Fernando Pinto wrote:
> Hello,
>
> ovl_fill_super() lowers CAP_SYS_RESOURCE in the creator credentials with
> the comment "Never override disk quota limits or use reserved space"
> (fs/overlayfs/super.c:1511 in v7.3-rc7). On an ext4 upper with the
> default reserve owner, the second half does not hold:
> ext4_has_free_clusters() grants the reserve when the allocating task's
> fsuid equals s_resuid, 0 by default, before it looks at the capability
> (fs/ext4/balloc.c:654-657). Writes through overlayfs run with the
> mounter's credentials (ovl_write_iter() sets .cred = ovl_creds(sb) and
> backing_file_write_iter() applies it), so with a root mounter the fsuid
> that reaches ext4 is 0, and an unprivileged writer can spend the blocks
> reserved for root.
I'm not sure why overlayfs is trying to override disk quota limits.
What's the background behind this?
/* Never override disk quota limits or use reserved space */
cap_lower(creator_cred->cap_effective, CAP_SYS_RESOURCE);
More the point, why do we have creator_cred in the first place? We're
not lowering CAP_FOWNER or CAP_DAC_OVERRIDE and fsuid is 0. So if
we're allowing some file system operations with the mounter's creds,
why is CAP_SYS_RESOURCE special? Also note that if fsuid is 0, then
regardless of CAP_SYS_RESOURCE, any writes will be charged against
user 0's quota, and user 0 doesn't have any limits (often it doesn't)
there won't be any disk quota limits anyway.
- Ted
next prev parent reply other threads:[~2026-10-20 3:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 9:03 overlayfs: unprivileged writes can use ext4's reserved blocks with the default resuid Claudio Fernando Pinto
2026-10-19 21:55 ` Amir Goldstein
2026-10-20 3:54 ` Theodore Tso [this message]
2026-10-20 8:39 ` Claudio Fernando Pinto
2026-10-20 21:27 ` Amir Goldstein
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=atbfAjLsKxhkqW-q@mit.edu \
--to=tytso@mit.edu \
--cc=amir73il@gmail.com \
--cc=claudiofernandopinto@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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