Re: [RFC PATCH 0/2] quota: opt-in strict enforcement of project quota hard limits

[Jan Kara]

On Fri 14-08-26 20:46:47, Kitae Yoo wrote:
> ignore_hardlimit() exempts CAP_SYS_RESOURCE holders from enforcement of
> hard limits (and of soft limits past their grace time), regardless of
> quota type, so it also covers project quotas.
> 
> For user/group quotas this matches the long-standing expectation that an
> administrator can act on a full filesystem. For project quotas it is a
> poor fit: a project limit bounds the size of a directory tree rather than
> restricting a user, and is commonly used for capacity isolation of
> container volumes and NFS-exported shares. There the exemption defeats
> the purpose. Two concrete cases:

Project quotas *can* be used for restricting size of the directory tree.
But it is not the only way how to use them (nothing really forces each
project files to form a tree).

>  1. A process holding CAP_SYS_RESOURCE (e.g. a privileged container)
>     writes past a project hard limit; accounting keeps rising above it.
> 
>  2. knfsd raises CAP_SYS_RESOURCE for requests mapped to root on
>     no_root_squash exports (CAP_NFSD_SET in <linux/capability.h>). So on
>     an ext4-backed, no_root_squash NFS export any remote root write
>     bypasses project hard limits, no matter how confined the client is.
>     We hit this while evaluating ext4 project quotas for multi-tenant NFS
>     volumes: with a 2 GiB hard limit, remote root writes proceeded well
>     past 2 GiB (v6.8, quotaon reporting "enforced"). The same setup on
>     XFS, whose enforcement path performs no capability check, stops the
>     write at the limit.

I would consider this a desirable behavior, not a bug. If you have
priviledged user, he/she should be able to overcome artificially imposed
limits. That was the design of quota subsystem from the early days. Running
as priviledged user in a container or without rootsquash on NFS is IMO a
bad security practice and such user can generally overcome the limits (e.g.
by changing file owners including owner project). So not only would this
break a long standing practice, I also don't see how this would
significantly change anything.

Sadly, XFS always had a separate quota implementation and as a result there
are subtle behavioral differences. In particular limits for
user/group/project 0 are treated as default limits for any user with unset
limits. I don't think they are expected to constrain root user.

> DQF_ROOT_SQUASH already disables this exemption, but setting it has been
> confined to the old v1 quota format, and commit ca6cb0918e87 ("quota:
> Verify flags passed to Q_SETINFO") later made Q_SETINFO reject it
> explicitly on other formats, on the grounds that those formats did not
> persist the flag and a flag silently lost on remount is confusing. That
> confinement predates generic project quota support (commit 847aac644e92
> "vfs: Add general support to enforce project quota limits").

DQF_ROOT_SQUASH was always intended to be limited to the old quota format.
For newer formats, we always allow setting limits even for
user/group/project 0 but we also respect process capabilities when checking
whether it can overcome the limits or not.

> This series lifts the restriction and addresses the persistence concern
> that motivated it:
> 
>   1/2 allows DQF_ROOT_SQUASH to be set through Q_SETINFO on all formats,
>       so it can be enabled per quota type (e.g. project only).
>   2/2 persists the flag in the v2 on-disk dqi_flags field, which already
>       exists, masking on read so only the supported flag is honoured -
>       which also keeps the pre-existing unvalidated on-disk bits (the
>       reason c119c5b9749e "quota: Don't store flags for v2 quota format"
>       stopped storing them) out of the in-memory state.

Thank you for your proposal but essentially you create a flag saying
"ignore CAP_SYS_RESOURCE for project quotas". As much as I can see how it
would be convenient for your setup, I think that is a bad design and would
create confusion down the road. All I can really recommend is to properly
separate priviledges for your processes and then you wouldn't have to come
up with hacks to ignore CAP_SYS_RESOURCE...

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR