[RFC PATCH] quota: allow unprivileged users to query ID 0 default limits

[RFC PATCH] quota: allow unprivileged users to query ID 0 default limits

[Ravi Singh]

Default quota limits are stored on the ID 0 dquot record and are
applied by the kernel to all users who have no explicit limits set.
However, check_quotactl_permission() only allows unprivileged users to
query their own user or group quota via Q_GETQUOTA/Q_XGETQUOTA.  This
means unprivileged users cannot discover what default limits apply to
them.

Allow any user to query ID 0's quota via Q_GETQUOTA/Q_XGETQUOTA.
Note that this does expose ID 0's usage counters and timers in
addition to the default limits. This enables userspace tools like
xfs_quota to fetch default limits and display them to unprivileged
users.

This change does not affect Q_XGETNEXTQUOTA, Q_SETQLIM, or any other
quota command -- those still require CAP_SYS_ADMIN.

Signed-off-by: Ravi Singh <ravising@redhat.com>
---
 fs/quota/quota.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/quota/quota.c b/fs/quota/quota.c
index 33bacd707..8b21f3c1b 100644
--- a/fs/quota/quota.c
+++ b/fs/quota/quota.c
@@ -42,6 +42,9 @@ static int check_quotactl_permission(struct super_block *sb, int type, int cmd,
 		if ((type == USRQUOTA && uid_eq(current_euid(), make_kuid(current_user_ns(), id))) ||
 		    (type == GRPQUOTA && in_egroup_p(make_kgid(current_user_ns(), id))))
 			break;
+		 /* Allow unprivileged read of ID 0 (default quota limits) */
+		if (id == 0)
+			break;
 		fallthrough;
 	default:
 		if (!capable(CAP_SYS_ADMIN))
-- 
2.49.0

Re: [RFC PATCH] quota: allow unprivileged users to query ID 0 default limits

[Andreas Dilger]

On Mar 12, 2026, at 03:08, Ravi Singh <ravising@redhat.com> wrote:
> 
> Default quota limits are stored on the ID 0 dquot record and are
> applied by the kernel to all users who have no explicit limits set.
> However, check_quotactl_permission() only allows unprivileged users to
> query their own user or group quota via Q_GETQUOTA/Q_XGETQUOTA.  This
> means unprivileged users cannot discover what default limits apply to
> them.
> 
> Allow any user to query ID 0's quota via Q_GETQUOTA/Q_XGETQUOTA.
> Note that this does expose ID 0's usage counters and timers in
> addition to the default limits. This enables userspace tools like
> xfs_quota to fetch default limits and display them to unprivileged
> users.

Showing the root user's quota usage may be confusing for the regular
user.  It seems better to filter out the quota usage in this case and
only expose the limits?

Alternately, should users without an explicit quota limit have the
default limits merged into their returned values, rather than them
needing to query id=0 separately for the limits?

Cheers, Andreas
> 
> This change does not affect Q_XGETNEXTQUOTA, Q_SETQLIM, or any other
> quota command -- those still require CAP_SYS_ADMIN.
> 
> Signed-off-by: Ravi Singh <ravising@redhat.com>
> ---
> fs/quota/quota.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/fs/quota/quota.c b/fs/quota/quota.c
> index 33bacd707..8b21f3c1b 100644
> --- a/fs/quota/quota.c
> +++ b/fs/quota/quota.c
> @@ -42,6 +42,9 @@ static int check_quotactl_permission(struct super_block *sb, int type, int cmd,
> if ((type == USRQUOTA && uid_eq(current_euid(), make_kuid(current_user_ns(), id))) ||
>    (type == GRPQUOTA && in_egroup_p(make_kgid(current_user_ns(), id))))
> break;
> + /* Allow unprivileged read of ID 0 (default quota limits) */
> + if (id == 0)
> + break;
> fallthrough;
> default:
> if (!capable(CAP_SYS_ADMIN))
> -- 
> 2.49.0
> 
> 

Re: [RFC PATCH] quota: allow unprivileged users to query ID 0 default limits

[Ravi Singh]

On Thu, Mar 12, 2026 at 3:15 PM Andreas Dilger <adilger@dilger.ca> wrote:
>
> On Mar 12, 2026, at 03:08, Ravi Singh <ravising@redhat.com> wrote:
> >
> > Default quota limits are stored on the ID 0 dquot record and are
> > applied by the kernel to all users who have no explicit limits set.
> > However, check_quotactl_permission() only allows unprivileged users to
> > query their own user or group quota via Q_GETQUOTA/Q_XGETQUOTA.  This
> > means unprivileged users cannot discover what default limits apply to
> > them.
> >
> > Allow any user to query ID 0's quota via Q_GETQUOTA/Q_XGETQUOTA.
> > Note that this does expose ID 0's usage counters and timers in
> > addition to the default limits. This enables userspace tools like
> > xfs_quota to fetch default limits and display them to unprivileged
> > users.
>
> Showing the root user's quota usage may be confusing for the regular
> user.  It seems better to filter out the quota usage in this case and
> only expose the limits?

Agreed, exposing root's usage data is unnecessary.

> Alternately, should users without an explicit quota limit have the
> default limits merged into their returned values, rather than them
> needing to query id=0 separately for the limits?

Yes, this is the better approach. I've reworked the patch to handle
this in xfs_qm_scall_getquota(), when xfs_qm_dqget() returns
-ENOENT for a non-zero ID, we now return zero usage with default
limits from xfs_get_defquota() instead of propagating the error.

This avoids any VFS permission changes and keeps root's usage data
private. The user queries their own ID through the existing
permission check, and the kernel returns the effective limits directly.

v2 posted as a separate thread.

Thanks,
Ravi

> Cheers, Andreas
> >
> > This change does not affect Q_XGETNEXTQUOTA, Q_SETQLIM, or any other
> > quota command -- those still require CAP_SYS_ADMIN.
> >
> > Signed-off-by: Ravi Singh <ravising@redhat.com>
> > ---
> > fs/quota/quota.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/fs/quota/quota.c b/fs/quota/quota.c
> > index 33bacd707..8b21f3c1b 100644
> > --- a/fs/quota/quota.c
> > +++ b/fs/quota/quota.c
> > @@ -42,6 +42,9 @@ static int check_quotactl_permission(struct super_block *sb, int type, int cmd,
> > if ((type == USRQUOTA && uid_eq(current_euid(), make_kuid(current_user_ns(), id))) ||
> >    (type == GRPQUOTA && in_egroup_p(make_kgid(current_user_ns(), id))))
> > break;
> > + /* Allow unprivileged read of ID 0 (default quota limits) */
> > + if (id == 0)
> > + break;
> > fallthrough;
> > default:
> > if (!capable(CAP_SYS_ADMIN))
> > --
> > 2.49.0
> >
> >
>

[PATCH v2] xfs: return default quota limits for IDs without a dquot

[Ravi Singh]

When an ID has no dquot on disk, Q_XGETQUOTA returns -ENOENT even
though default quota limits are configured and enforced against that
ID.  This means unprivileged users who have never used any resources
cannot see the limits that apply to them.

When xfs_qm_dqget() returns -ENOENT for a non-zero ID, return a
zero-usage response with the default limits filled in from
m_quotainfo rather than propagating the error.  This is consistent
with the enforcement behavior in xfs_qm_adjust_dqlimits(), which
pushes the same default limits into a dquot when it is first
allocated.

Signed-off-by: Ravi Singh <ravising@redhat.com>
---
 v2:
  - Moved fix from VFS (fs/quota/quota.c) to XFS
    (fs/xfs/xfs_qm_syscalls.c) per review feedback
  - Return default limits on ENOENT instead of granting
    unprivileged access to ID 0's dquot

 fs/xfs/xfs_qm_syscalls.c | 36 +++++++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_qm_syscalls.c b/fs/xfs/xfs_qm_syscalls.c
index d50b7318c..2176dc617 100644
--- a/fs/xfs/xfs_qm_syscalls.c
+++ b/fs/xfs/xfs_qm_syscalls.c
@@ -391,6 +391,30 @@ xfs_qm_scall_setqlim(
 	return error;
 }
 
+/*
+ * Fill out the default quota limits for an ID that has no dquot on disk.
+ * The default limits are enforced against such IDs by
+ * xfs_qm_adjust_dqlimits() when a dquot is first allocated.
+ */
+static void
+xfs_qm_scall_getquota_fill_defaults(
+	struct xfs_mount	*mp,
+	xfs_dqtype_t		type,
+	struct qc_dqblk		*dst)
+{
+	struct xfs_def_quota	*defq;
+
+	defq = xfs_get_defquota(mp->m_quotainfo, type);
+
+	memset(dst, 0, sizeof(*dst));
+	dst->d_spc_softlimit = XFS_FSB_TO_B(mp, defq->blk.soft);
+	dst->d_spc_hardlimit = XFS_FSB_TO_B(mp, defq->blk.hard);
+	dst->d_ino_softlimit = defq->ino.soft;
+	dst->d_ino_hardlimit = defq->ino.hard;
+	dst->d_rt_spc_softlimit = XFS_FSB_TO_B(mp, defq->rtb.soft);
+	dst->d_rt_spc_hardlimit = XFS_FSB_TO_B(mp, defq->rtb.hard);
+}
+
 /* Fill out the quota context. */
 static void
 xfs_qm_scall_getquota_fill_qc(
@@ -451,8 +475,18 @@ xfs_qm_scall_getquota(
 	 * set doalloc. If it doesn't exist, we'll get ENOENT back.
 	 */
 	error = xfs_qm_dqget(mp, id, type, false, &dqp);
-	if (error)
+	if (error) {
+		/*
+		 * If there is no dquot for this ID and it is not ID 0,
+		 * return the default limits with zero usage so that
+		 * unprivileged users can see what limits apply to them.
+		 */
+		if (error == -ENOENT && id != 0) {
+			xfs_qm_scall_getquota_fill_defaults(mp, type, dst);
+			return 0;
+		}
 		return error;
+	}
 
 	/*
 	 * If everything's NULL, this dquot doesn't quite exist as far as
-- 
2.49.0

Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Jan Kara]

On Tue 17-03-26 14:59:47, Ravi Singh wrote:
> When an ID has no dquot on disk, Q_XGETQUOTA returns -ENOENT even
> though default quota limits are configured and enforced against that
> ID.  This means unprivileged users who have never used any resources
> cannot see the limits that apply to them.
> 
> When xfs_qm_dqget() returns -ENOENT for a non-zero ID, return a
> zero-usage response with the default limits filled in from
> m_quotainfo rather than propagating the error.  This is consistent
> with the enforcement behavior in xfs_qm_adjust_dqlimits(), which
> pushes the same default limits into a dquot when it is first
> allocated.
> 
> Signed-off-by: Ravi Singh <ravising@redhat.com>

So XFS guys should also review this but from quota POV this looks like a
right fix to me. So feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  v2:
>   - Moved fix from VFS (fs/quota/quota.c) to XFS
>     (fs/xfs/xfs_qm_syscalls.c) per review feedback
>   - Return default limits on ENOENT instead of granting
>     unprivileged access to ID 0's dquot
> 
>  fs/xfs/xfs_qm_syscalls.c | 36 +++++++++++++++++++++++++++++++++++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/xfs/xfs_qm_syscalls.c b/fs/xfs/xfs_qm_syscalls.c
> index d50b7318c..2176dc617 100644
> --- a/fs/xfs/xfs_qm_syscalls.c
> +++ b/fs/xfs/xfs_qm_syscalls.c
> @@ -391,6 +391,30 @@ xfs_qm_scall_setqlim(
>  	return error;
>  }
>  
> +/*
> + * Fill out the default quota limits for an ID that has no dquot on disk.
> + * The default limits are enforced against such IDs by
> + * xfs_qm_adjust_dqlimits() when a dquot is first allocated.
> + */
> +static void
> +xfs_qm_scall_getquota_fill_defaults(
> +	struct xfs_mount	*mp,
> +	xfs_dqtype_t		type,
> +	struct qc_dqblk		*dst)
> +{
> +	struct xfs_def_quota	*defq;
> +
> +	defq = xfs_get_defquota(mp->m_quotainfo, type);
> +
> +	memset(dst, 0, sizeof(*dst));
> +	dst->d_spc_softlimit = XFS_FSB_TO_B(mp, defq->blk.soft);
> +	dst->d_spc_hardlimit = XFS_FSB_TO_B(mp, defq->blk.hard);
> +	dst->d_ino_softlimit = defq->ino.soft;
> +	dst->d_ino_hardlimit = defq->ino.hard;
> +	dst->d_rt_spc_softlimit = XFS_FSB_TO_B(mp, defq->rtb.soft);
> +	dst->d_rt_spc_hardlimit = XFS_FSB_TO_B(mp, defq->rtb.hard);
> +}
> +
>  /* Fill out the quota context. */
>  static void
>  xfs_qm_scall_getquota_fill_qc(
> @@ -451,8 +475,18 @@ xfs_qm_scall_getquota(
>  	 * set doalloc. If it doesn't exist, we'll get ENOENT back.
>  	 */
>  	error = xfs_qm_dqget(mp, id, type, false, &dqp);
> -	if (error)
> +	if (error) {
> +		/*
> +		 * If there is no dquot for this ID and it is not ID 0,
> +		 * return the default limits with zero usage so that
> +		 * unprivileged users can see what limits apply to them.
> +		 */
> +		if (error == -ENOENT && id != 0) {
> +			xfs_qm_scall_getquota_fill_defaults(mp, type, dst);
> +			return 0;
> +		}
>  		return error;
> +	}
>  
>  	/*
>  	 * If everything's NULL, this dquot doesn't quite exist as far as
> -- 
> 2.49.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Theodore Tso]

On Tue, Mar 17, 2026 at 01:19:23PM +0100, Jan Kara wrote:
> On Tue 17-03-26 14:59:47, Ravi Singh wrote:
> > When an ID has no dquot on disk, Q_XGETQUOTA returns -ENOENT even
> > though default quota limits are configured and enforced against that
> > ID.  This means unprivileged users who have never used any resources
> > cannot see the limits that apply to them.
> > 
> > When xfs_qm_dqget() returns -ENOENT for a non-zero ID, return a
> > zero-usage response with the default limits filled in from
> > m_quotainfo rather than propagating the error.  This is consistent
> > with the enforcement behavior in xfs_qm_adjust_dqlimits(), which
> > pushes the same default limits into a dquot when it is first
> > allocated.
> > 
> > Signed-off-by: Ravi Singh <ravising@redhat.com>
> 
> So XFS guys should also review this but from quota POV this looks like a
> right fix to me. So feel free to add:
> 
> Reviewed-by: Jan Kara <jack@suse.cz>

This was discussed at last week's ext4 conference call, and we
wondered whether we might be better off adding a new
Q_XGETDEFAULTQUOTA or some such which returned the default quota.
This would that the quota userspace utilities would have to be
changed, but it would also mean that userspace could distinguish
between whether the quota limit was due to a default value being used,
or because the user had an actual quota value set.

It also means that in the future, if we wanted to change where the
default quota was stored, it would be possible to do that instead of
overloading the quota value for uid/gid 0.

We also speculated that perhaps there might be cases where if some
process might be running without CAP_SYS_ADMIN, there might be a
reason that quota for uid=0 might actually make sense, and so perhaps
some future file system format change might want to decouple where the
default quota was stored.

This is a API question, and given that I don't really care a whole lot
about quotas (we use quota only for tracking usage, not for actually
enforce quota limits, so I really don't care that much), what do folks
think makes the most amount of sense?

						- Ted

Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Jan Kara]

Hello!

On Tue 17-03-26 09:31:59, Theodore Tso wrote:
> On Tue, Mar 17, 2026 at 01:19:23PM +0100, Jan Kara wrote:
> > On Tue 17-03-26 14:59:47, Ravi Singh wrote:
> > > When an ID has no dquot on disk, Q_XGETQUOTA returns -ENOENT even
> > > though default quota limits are configured and enforced against that
> > > ID.  This means unprivileged users who have never used any resources
> > > cannot see the limits that apply to them.
> > > 
> > > When xfs_qm_dqget() returns -ENOENT for a non-zero ID, return a
> > > zero-usage response with the default limits filled in from
> > > m_quotainfo rather than propagating the error.  This is consistent
> > > with the enforcement behavior in xfs_qm_adjust_dqlimits(), which
> > > pushes the same default limits into a dquot when it is first
> > > allocated.
> > > 
> > > Signed-off-by: Ravi Singh <ravising@redhat.com>
> > 
> > So XFS guys should also review this but from quota POV this looks like a
> > right fix to me. So feel free to add:
> > 
> > Reviewed-by: Jan Kara <jack@suse.cz>
> 
> This was discussed at last week's ext4 conference call, and we
> wondered whether we might be better off adding a new
> Q_XGETDEFAULTQUOTA or some such which returned the default quota.
> This would that the quota userspace utilities would have to be
> changed, but it would also mean that userspace could distinguish
> between whether the quota limit was due to a default value being used,
> or because the user had an actual quota value set.

First thing to note is that the notion of "default limit" is specific to
XFS. Other filesystems using quota don't have any default limits. I guess
most people here know this but I'm spelling it out so that we are all on
the same page.

> It also means that in the future, if we wanted to change where the
> default quota was stored, it would be possible to do that instead of
> overloading the quota value for uid/gid 0.
> 
> We also speculated that perhaps there might be cases where if some
> process might be running without CAP_SYS_ADMIN, there might be a
> reason that quota for uid=0 might actually make sense, and so perhaps
> some future file system format change might want to decouple where the
> default quota was stored.

Right. That's why I didn't like the v1 version of the patch. But v2 version
hides the XFS specific behavior of default limits inside XFS function for
fetching quotas so that is fully transparent. If XFS decides to change its
quota format to support limits for root, it can also change this code
fetching and filling in default limits for the user. So until XFS decides
to change the format, current solution looks fine to me, once it decides to
change it, it is easy to change this code as well. But obviously this is
fully XFS developers' area of code so they can do whatever they wish :)

The only improvement I can see is if we explicitely wanted to expose the
XFS default limits in some generic way for userspace tools to show. But
then I'd think we don't really need new quotactl, we could just put this
into the result of existing Q_XGETQSTATV quotactl.

Overall I don't have a strong opinion on this and consider these questions
mostly specific to XFS so XFS guys should decide what they want...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Darrick J. Wong]

On Wed, Mar 18, 2026 at 06:29:47PM +0100, Jan Kara wrote:
> Hello!
> 
> On Tue 17-03-26 09:31:59, Theodore Tso wrote:
> > On Tue, Mar 17, 2026 at 01:19:23PM +0100, Jan Kara wrote:
> > > On Tue 17-03-26 14:59:47, Ravi Singh wrote:
> > > > When an ID has no dquot on disk, Q_XGETQUOTA returns -ENOENT even
> > > > though default quota limits are configured and enforced against that
> > > > ID.  This means unprivileged users who have never used any resources
> > > > cannot see the limits that apply to them.
> > > > 
> > > > When xfs_qm_dqget() returns -ENOENT for a non-zero ID, return a
> > > > zero-usage response with the default limits filled in from
> > > > m_quotainfo rather than propagating the error.  This is consistent
> > > > with the enforcement behavior in xfs_qm_adjust_dqlimits(), which
> > > > pushes the same default limits into a dquot when it is first
> > > > allocated.
> > > > 
> > > > Signed-off-by: Ravi Singh <ravising@redhat.com>
> > > 
> > > So XFS guys should also review this but from quota POV this looks like a
> > > right fix to me. So feel free to add:
> > > 
> > > Reviewed-by: Jan Kara <jack@suse.cz>
> > 
> > This was discussed at last week's ext4 conference call, and we
> > wondered whether we might be better off adding a new
> > Q_XGETDEFAULTQUOTA or some such which returned the default quota.
> > This would that the quota userspace utilities would have to be
> > changed, but it would also mean that userspace could distinguish
> > between whether the quota limit was due to a default value being used,
> > or because the user had an actual quota value set.
> 
> First thing to note is that the notion of "default limit" is specific to
> XFS. Other filesystems using quota don't have any default limits. I guess
> most people here know this but I'm spelling it out so that we are all on
> the same page.

*I* actually didn't know that, so thank you for pointing that out!!

> > It also means that in the future, if we wanted to change where the
> > default quota was stored, it would be possible to do that instead of
> > overloading the quota value for uid/gid 0.
> > 
> > We also speculated that perhaps there might be cases where if some
> > process might be running without CAP_SYS_ADMIN, there might be a
> > reason that quota for uid=0 might actually make sense, and so perhaps
> > some future file system format change might want to decouple where the
> > default quota was stored.
> 
> Right. That's why I didn't like the v1 version of the patch. But v2 version
> hides the XFS specific behavior of default limits inside XFS function for
> fetching quotas so that is fully transparent. If XFS decides to change its
> quota format to support limits for root, it can also change this code

Wait, do the other filesystems enforce limits on id 0?

Also, do those non-xfs filesystems also not have default limits?

> fetching and filling in default limits for the user. So until XFS decides
> to change the format, current solution looks fine to me, once it decides to
> change it, it is easy to change this code as well. But obviously this is
> fully XFS developers' area of code so they can do whatever they wish :)

/me bets nobody cares that much in xfsland other than not breaking
userspace tools. ;)

> The only improvement I can see is if we explicitely wanted to expose the
> XFS default limits in some generic way for userspace tools to show. But
> then I'd think we don't really need new quotactl, we could just put this
> into the result of existing Q_XGETQSTATV quotactl.
> 
> Overall I don't have a strong opinion on this and consider these questions
> mostly specific to XFS so XFS guys should decide what they want...

We're stuck with the old ABI behavior unless you all want to add a
Q_<whatever>V2 quotactl command.

--D

> 
> 								Honza
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
> 

Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Jan Kara]

On Wed 18-03-26 15:18:10, Darrick J. Wong wrote:
> On Wed, Mar 18, 2026 at 06:29:47PM +0100, Jan Kara wrote:
> > Hello!
> > 
> > On Tue 17-03-26 09:31:59, Theodore Tso wrote:
> > > On Tue, Mar 17, 2026 at 01:19:23PM +0100, Jan Kara wrote:
> > > > On Tue 17-03-26 14:59:47, Ravi Singh wrote:
> > > > > When an ID has no dquot on disk, Q_XGETQUOTA returns -ENOENT even
> > > > > though default quota limits are configured and enforced against that
> > > > > ID.  This means unprivileged users who have never used any resources
> > > > > cannot see the limits that apply to them.
> > > > > 
> > > > > When xfs_qm_dqget() returns -ENOENT for a non-zero ID, return a
> > > > > zero-usage response with the default limits filled in from
> > > > > m_quotainfo rather than propagating the error.  This is consistent
> > > > > with the enforcement behavior in xfs_qm_adjust_dqlimits(), which
> > > > > pushes the same default limits into a dquot when it is first
> > > > > allocated.
> > > > > 
> > > > > Signed-off-by: Ravi Singh <ravising@redhat.com>
> > > > 
> > > > So XFS guys should also review this but from quota POV this looks like a
> > > > right fix to me. So feel free to add:
> > > > 
> > > > Reviewed-by: Jan Kara <jack@suse.cz>
> > > 
> > > This was discussed at last week's ext4 conference call, and we
> > > wondered whether we might be better off adding a new
> > > Q_XGETDEFAULTQUOTA or some such which returned the default quota.
> > > This would that the quota userspace utilities would have to be
> > > changed, but it would also mean that userspace could distinguish
> > > between whether the quota limit was due to a default value being used,
> > > or because the user had an actual quota value set.
> > 
> > First thing to note is that the notion of "default limit" is specific to
> > XFS. Other filesystems using quota don't have any default limits. I guess
> > most people here know this but I'm spelling it out so that we are all on
> > the same page.
> 
> *I* actually didn't know that, so thank you for pointing that out!!

Then I'm happy I've spelled it out :)

> > > It also means that in the future, if we wanted to change where the
> > > default quota was stored, it would be possible to do that instead of
> > > overloading the quota value for uid/gid 0.
> > > 
> > > We also speculated that perhaps there might be cases where if some
> > > process might be running without CAP_SYS_ADMIN, there might be a
> > > reason that quota for uid=0 might actually make sense, and so perhaps
> > > some future file system format change might want to decouple where the
> > > default quota was stored.
> > 
> > Right. That's why I didn't like the v1 version of the patch. But v2 version
> > hides the XFS specific behavior of default limits inside XFS function for
> > fetching quotas so that is fully transparent. If XFS decides to change its
> > quota format to support limits for root, it can also change this code
> 
> Wait, do the other filesystems enforce limits on id 0?

Yes, generic quota subsystem doesn't treat id 0 in any special way.
Normally CAP_SYS_RESOURCE check makes the limits irrelevant but with user
namespaces uid 0 can be limited with quota limit e.g. on ext4.

> Also, do those non-xfs filesystems also not have default limits?

Yes, generic quota formats (used by ext2, ext4, ocfs2, f2fs) don't have
default limits. Userspace is responsible to set quota limits using quota
tools when creating user account. GFS2 does its own thing but AFAICS it
doesn't have a notion of default quota limit either.

> > fetching and filling in default limits for the user. So until XFS decides
> > to change the format, current solution looks fine to me, once it decides to
> > change it, it is easy to change this code as well. But obviously this is
> > fully XFS developers' area of code so they can do whatever they wish :)
> 
> /me bets nobody cares that much in xfsland other than not breaking
> userspace tools. ;)
> 
> > The only improvement I can see is if we explicitely wanted to expose the
> > XFS default limits in some generic way for userspace tools to show. But
> > then I'd think we don't really need new quotactl, we could just put this
> > into the result of existing Q_XGETQSTATV quotactl.
> > 
> > Overall I don't have a strong opinion on this and consider these questions
> > mostly specific to XFS so XFS guys should decide what they want...
> 
> We're stuck with the old ABI behavior unless you all want to add a
> Q_<whatever>V2 quotactl command.

Well, the Q_XGETQSTATV quotactl has quite a few free padding space in the
struct so the default limits could be put there if somebody cared enough...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Ravi Singh]

Hi all,

Thanks for the feedback. Before posting a v3, I wanted to share some
additional findings. The v2 patch only covers one of three scenarios
where an unprivileged user cannot see the default limits applying to them.

Scenario 1: No dquot on disk (v2 fixes this):
xfs_qm_dqget() returns -ENOENT, and v2 catches it.

mkfs.xfs /dev/vde -f
mount -o quota /dev/vde /mnt/test
xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
# Do NOT chown anything to testuser8 - no dquot exists
su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"

Without fix: empty output
With fix:
Disk quotas for User testuser8 (1003)
Filesystem              Blocks      Quota      Limit  Warn/Time      Mounted on
 /dev/vde                     0      10240      20480   00 [--------] /mnt/test

Scenario 2: dquot exists with non-zero counts but zero limits (v2 does NOT fix):

A dquot is created for testuser8 before default limits are configured.
When the chown runs, xfs_qm_adjust_dqlimits() is called in
xfs_trans_apply_dquot_deltas(), but the defaults are all zero at that
point so nothing is pushed into the dquot. When the admin later sets
limits on ID 0, testuser8's existing dquot is not retroactively updated.
xfs_qm_dqget() succeeds and XFS_IS_DQUOT_UNINITIALIZED is
false (q_ino.count != 0), so xfs_qm_scall_getquota_fill_qc() returns
the dquot's zero limits.

mkfs.xfs /dev/vde -f
mount -o quota /dev/vde /mnt/test
mkdir /mnt/test/testuser8
chown testuser8:testuser8 /mnt/test/testuser8
xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
# empty output

Scenario 3 : dquot all zeros / XFS_IS_DQUOT_UNINITIALIZED (v2 does NOT fix):

A dquot record persists on disk with all zero fields after ownership
is transferred away. xfs_qm_dqget() succeeds, but XFS_IS_DQUOT_UNINITIALIZED
returns true and the query returns -ENOENT. The v2 fallback does not
trigger because it only handles the xfs_qm_dqget() error path.

mkfs.xfs /dev/vde -f
mount -o quota /dev/vde /mnt/test
mkdir /mnt/test/testuser8
chown testuser8:testuser8 /mnt/test/testuser8
chown root:root /mnt/test/testuser8
xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
# empty output

I see two approaches for v3 and would appreciate guidance:

1. Fix all three in xfs_qm_scall_getquota() by merging default limits
    into the response for any zero-valued limit field, mirroring
    xfs_qm_adjust_dqlimits().
2.  Expose default limits through Q_XGETQSTATV using the available
     padding space in fs_quota_statv, as Jan suggested, and let
     userspace tools merge them.

Thoughts?

Thanks,
Ravi

Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Darrick J. Wong]

On Mon, Mar 23, 2026 at 04:55:31PM +0530, Ravi Singh wrote:
> Hi all,
> 
> Thanks for the feedback. Before posting a v3, I wanted to share some
> additional findings. The v2 patch only covers one of three scenarios
> where an unprivileged user cannot see the default limits applying to them.
> 
> Scenario 1: No dquot on disk (v2 fixes this):
> xfs_qm_dqget() returns -ENOENT, and v2 catches it.
> 
> mkfs.xfs /dev/vde -f
> mount -o quota /dev/vde /mnt/test
> xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
> # Do NOT chown anything to testuser8 - no dquot exists
> su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
> 
> Without fix: empty output
> With fix:
> Disk quotas for User testuser8 (1003)
> Filesystem              Blocks      Quota      Limit  Warn/Time      Mounted on
>  /dev/vde                     0      10240      20480   00 [--------] /mnt/test

Hmm, yes, that looks like a bug to me.

> Scenario 2: dquot exists with non-zero counts but zero limits (v2 does NOT fix):
> 
> A dquot is created for testuser8 before default limits are configured.
> When the chown runs, xfs_qm_adjust_dqlimits() is called in
> xfs_trans_apply_dquot_deltas(), but the defaults are all zero at that
> point so nothing is pushed into the dquot. When the admin later sets
> limits on ID 0, testuser8's existing dquot is not retroactively updated.
> xfs_qm_dqget() succeeds and XFS_IS_DQUOT_UNINITIALIZED is
> false (q_ino.count != 0), so xfs_qm_scall_getquota_fill_qc() returns
> the dquot's zero limits.

I think this is a difference in opinion -- the last time I checked, the
default limits are only supposed to be propagated to newly allocated
ondisk dquots.

It's true that it would make more sense if the ondisk dquot had a flag
to say "I've had limits applied here" such that default limits would
apply to a dquot that already existed on disk but hadn't had limits set.
Plus then you could modify a dquot with explicit limits to revert back
to the defaults.

Unfortunately there's no such flag in the ondisk format so we'd have to
rev the disk format to add that behavior.  As such ... I don't think
this is easily fixable.  The only way you could revert to defaults is
if...

> mkfs.xfs /dev/vde -f
> mount -o quota /dev/vde /mnt/test
> mkdir /mnt/test/testuser8
> chown testuser8:testuser8 /mnt/test/testuser8
> xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
> su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
> # empty output
> 
> Scenario 3 : dquot all zeros / XFS_IS_DQUOT_UNINITIALIZED (v2 does NOT fix):
> 
> A dquot record persists on disk with all zero fields after ownership
> is transferred away. xfs_qm_dqget() succeeds, but XFS_IS_DQUOT_UNINITIALIZED
> returns true and the query returns -ENOENT. The v2 fallback does not
> trigger because it only handles the xfs_qm_dqget() error path.

...you delete all usage for the dquot and set the limits to zero, right?
Or does setting the limits to zero actually work even if there's quota
usage?

Either way if the ondisk dquot is totally uninitialized then I don't
think we need to emit a record unless there's also a default limit.

> mkfs.xfs /dev/vde -f
> mount -o quota /dev/vde /mnt/test
> mkdir /mnt/test/testuser8
> chown testuser8:testuser8 /mnt/test/testuser8
> chown root:root /mnt/test/testuser8
> xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
> su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
> # empty output
> 
> I see two approaches for v3 and would appreciate guidance:
> 
> 1. Fix all three in xfs_qm_scall_getquota() by merging default limits
>     into the response for any zero-valued limit field, mirroring
>     xfs_qm_adjust_dqlimits().
> 2.  Expose default limits through Q_XGETQSTATV using the available
>      padding space in fs_quota_statv, as Jan suggested, and let
>      userspace tools merge them.
> 
> Thoughts?

I don't think we should create more userspace abi since nobody seems to
think that anyone uses quota limit reporting aggressively.  But if
anyone does, now would be a good time to say something.

--D

> Thanks,
> Ravi
> 
> 

Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Christoph Hellwig]

On Tue, Mar 24, 2026 at 05:16:21PM -0700, Darrick J. Wong wrote:
> > Without fix: empty output
> > With fix:
> > Disk quotas for User testuser8 (1003)
> > Filesystem              Blocks      Quota      Limit  Warn/Time      Mounted on
> >  /dev/vde                     0      10240      20480   00 [--------] /mnt/test
> 
> Hmm, yes, that looks like a bug to me.

Agreed.

> > Scenario 2: dquot exists with non-zero counts but zero limits (v2 does NOT fix):
> > 
> > A dquot is created for testuser8 before default limits are configured.
> > When the chown runs, xfs_qm_adjust_dqlimits() is called in
> > xfs_trans_apply_dquot_deltas(), but the defaults are all zero at that
> > point so nothing is pushed into the dquot. When the admin later sets
> > limits on ID 0, testuser8's existing dquot is not retroactively updated.
> > xfs_qm_dqget() succeeds and XFS_IS_DQUOT_UNINITIALIZED is
> > false (q_ino.count != 0), so xfs_qm_scall_getquota_fill_qc() returns
> > the dquot's zero limits.
> 
> I think this is a difference in opinion -- the last time I checked, the
> default limits are only supposed to be propagated to newly allocated
> ondisk dquots.

Yes.

> I don't think we should create more userspace abi since nobody seems to
> think that anyone uses quota limit reporting aggressively.  But if
> anyone does, now would be a good time to say something.

Agreed.  The fix one looks sensible, and everything else at this point
feels like a candidate for better documentation of the current
semantics.

Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Ravi Singh]

On Wed, Mar 25, 2026 at 5:46 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Mon, Mar 23, 2026 at 04:55:31PM +0530, Ravi Singh wrote:
> > Hi all,
> >
> > Thanks for the feedback. Before posting a v3, I wanted to share some
> > additional findings. The v2 patch only covers one of three scenarios
> > where an unprivileged user cannot see the default limits applying to them.
> >
> > Scenario 1: No dquot on disk (v2 fixes this):
> > xfs_qm_dqget() returns -ENOENT, and v2 catches it.
> >
> > mkfs.xfs /dev/vde -f
> > mount -o quota /dev/vde /mnt/test
> > xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
> > # Do NOT chown anything to testuser8 - no dquot exists
> > su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
> >
> > Without fix: empty output
> > With fix:
> > Disk quotas for User testuser8 (1003)
> > Filesystem              Blocks      Quota      Limit  Warn/Time      Mounted on
> >  /dev/vde                     0      10240      20480   00 [--------] /mnt/test
>
> Hmm, yes, that looks like a bug to me.

Thanks for confirming.

>
> > Scenario 2: dquot exists with non-zero counts but zero limits (v2 does NOT fix):
> >
> > A dquot is created for testuser8 before default limits are configured.
> > When the chown runs, xfs_qm_adjust_dqlimits() is called in
> > xfs_trans_apply_dquot_deltas(), but the defaults are all zero at that
> > point so nothing is pushed into the dquot. When the admin later sets
> > limits on ID 0, testuser8's existing dquot is not retroactively updated.
> > xfs_qm_dqget() succeeds and XFS_IS_DQUOT_UNINITIALIZED is
> > false (q_ino.count != 0), so xfs_qm_scall_getquota_fill_qc() returns
> > the dquot's zero limits.
>
> I think this is a difference in opinion -- the last time I checked, the
> default limits are only supposed to be propagated to newly allocated
> ondisk dquots.

Understood: Scenario 2 is by design.

>
> It's true that it would make more sense if the ondisk dquot had a flag
> to say "I've had limits applied here" such that default limits would
> apply to a dquot that already existed on disk but hadn't had limits set.
> Plus then you could modify a dquot with explicit limits to revert back
> to the defaults.
>
> Unfortunately there's no such flag in the ondisk format so we'd have to
> rev the disk format to add that behavior.  As such ... I don't think
> this is easily fixable.  The only way you could revert to defaults is
> if...
>
> > mkfs.xfs /dev/vde -f
> > mount -o quota /dev/vde /mnt/test
> > mkdir /mnt/test/testuser8
> > chown testuser8:testuser8 /mnt/test/testuser8
> > xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
> > su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
> > # empty output
> >
> > Scenario 3 : dquot all zeros / XFS_IS_DQUOT_UNINITIALIZED (v2 does NOT fix):
> >
> > A dquot record persists on disk with all zero fields after ownership
> > is transferred away. xfs_qm_dqget() succeeds, but XFS_IS_DQUOT_UNINITIALIZED
> > returns true and the query returns -ENOENT. The v2 fallback does not
> > trigger because it only handles the xfs_qm_dqget() error path.
>
> ...you delete all usage for the dquot and set the limits to zero, right?
> Or does setting the limits to zero actually work even if there's quota
> usage?

Setting limits to zero alone isn't enough. XFS_IS_DQUOT_UNINITIALIZED
checks both limits and counts (q_blk.count, q_rtb.count, q_ino.count),
so all of them must be zero. In the reproduction, the chown back to
root moves the inode count back to 0, that's what makes all fields zero.
If the user still owns any files, q_ino.count would be non-zero
and the dquot would not be considered uninitialized.

>
> Either way if the ondisk dquot is totally uninitialized then I don't
> think we need to emit a record unless there's also a default limit.
>
> > mkfs.xfs /dev/vde -f
> > mount -o quota /dev/vde /mnt/test
> > mkdir /mnt/test/testuser8
> > chown testuser8:testuser8 /mnt/test/testuser8
> > chown root:root /mnt/test/testuser8
> > xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
> > su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
> > # empty output
> >
> > I see two approaches for v3 and would appreciate guidance:
> >
> > 1. Fix all three in xfs_qm_scall_getquota() by merging default limits
> >     into the response for any zero-valued limit field, mirroring
> >     xfs_qm_adjust_dqlimits().
> > 2.  Expose default limits through Q_XGETQSTATV using the available
> >      padding space in fs_quota_statv, as Jan suggested, and let
> >      userspace tools merge them.
> >
> > Thoughts?
>
> I don't think we should create more userspace abi since nobody seems to
> think that anyone uses quota limit reporting aggressively.  But if
> anyone does, now would be a good time to say something.

Agreed. Thanks for the feedback!

>
> --D
>
> > Thanks,
> > Ravi
> >
> >
>