Message-Id: <A501A3E0-1823-41CE-97ED-4C64BE98FAE7@dilger.ca>
Date:   Mon, 21 Oct 2019 15:15:31 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        Wang Shilong <wangshilong1991@...il.com>,
        linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Li Xi <lixi@....com>, Wang Shilong <wshilong@....com>
Subject: Re: [Project Quota]file owner could change its project ID?

On Oct 20, 2019, at 4:25 PM, Theodore Y. Ts'o <tytso@....edu> wrote:
> 
> On Sun, Oct 20, 2019 at 02:19:19PM -0600, Andreas Dilger wrote:
>>> We could also solve the problem by adding an LSM hook called when
>>> there is an attempt to set the project ID, and for people who really
>>> want this, they can create a stackable LSM which enforces whatever
>>> behavior they want.
>> 
>> So, rather than add a few-line change that decides whether the user
>> is allowed to change the projid for a file, we would instead add *more*
>> lines to add a hook, then have to write and load an LSM that is called
>> each time?  That seems backward to me.
> 
> I'm just not sure we've necessarily gotten the semantics right.  For
> example, I could easily see someone else coming out of the woodwork
> saying that The Right Model (tm) is one where users belong to a number
> of projects (much like supplementary group ID's) and you should be
> able to set the project of any file that you own to a project.

Definitely I've thought of that kind of behavior, but it needs a much larger
change, and is not clear that anyone actually needs this yet.  It is not
incompatible with the "add an option for root-only (or specific GID-only)
'setprojid' permission", but rather would be an enhancement that could be
added after the fact (there is no need for it with the "free for all" today).
However, I'm uncertain whether any benefit would be had from "supplementary
projid" support as you describe or not.

If a user has write permission in a target directory with a different projid
then they can easily (with "mv" handling the EXDEV case automatically) move
files from a source projid to a target projid by copying the data through
userspace.  In this respect, I wonder why ext4 enforces the "can't rename
to a target directory with a different projid" restriction that XFS has?  It
seems possible (very beneficial even) to change the projid in ext4 when a
file is renamed to a different directory, rather than forcing a full-file
copy in userspace, which can be very slow if the file is large.

Essentially the permission check for rename() could become "if user has write
permission in the target directory with a different projid, then allow the
change" since they could just as easily bypass the permissions in userspace.

According to Dave's original post this is an "XFS implementation detail":
https://www.spinics.net/lists/linux-ext4/msg44738.html

    XFS doesn't transfer the quota from projid to projid because it's
    borderline impossible to correctly track all the metadata
    allocation/free operations that can happen in a rename operation and
    account them to the correct quota. Hence all those corner cases are
    avoided by treating it as EXDEV and forcing userspace to cp/unlink
    the files rather than rename.

    That's really an implementation detail.

If we don't have this problem in ext4 then we don't need to return -EXDEV.

However, that is digressing from the original point of "restrict permission"
rather than "allow for rename".

> Or perhaps the policy is that you can only change the project ID if
> the project ID has a non-zero project quota.  etc.
> 
>>> If we think this going to be an speciality request, this might be the
>>> better way to go.
>> 
>> I don't see how this is more "speciality" than regular quota enforcement?
>> Just like we impose limits on users and groups, it makes sense to impose
>> a limit on a project, instead of just tracking it and then having to add
>> extra machinery to impose the limit externally.
> 
> We *do* have regular quota enforcement.  The question here has nothing
> to do with how quota tracking or enforcement work.  The question is
> about what are the authorization checks and policy surrounding when
> the project ID can modified.

> 
> Right now the policy is "the owner of the file can set the project ID
> to any integer if it is issued from the initial user namespace;
> otherwise, no changes to the project ID or the PROJINHERIT flag is
> allowed".

IMHO, if any user can arbitrarily change the projid of a file, that prevents
effective project quota enforcement.

> Making it be "only root in the inital user namespace is allowed change
> project ID or PROJINHERIT flag" is certain an alternate policy.  Are
> we sure those are the only two possible policies that users might ask
> for?

No, but at the risk of bike-shedding this too much in advance of actual user
need for a more complex mechanism, preventing users from arbitrarily shedding
quota to other projects seems very useful.  The restrictive and traditional
method is to allow only root (uid==0) to do this, but modern systems try to
avoid this by using e.g. CAP_SYS_RESOURCE (which is used for other quota
changes).  A slightly more flexible method would be to allow a group (e.g.
"wheel" or "admin") to also control project IDs for files/directories.  This
would default to GID=0 to start (root only), or could default to GID=-1 (any
group can change) to match the current behavior.  Defaulting to GID=-1 would
have the benefit that the mechanism for restricting "setprojid" could be added
but keep the same behavior as today, but make it easy to change if desired.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)

Powered by blists - more mailing lists