Re: [PATCH v2 0/4] quota: add project quota support

[Theodore Ts'o <tytso@mit.edu>]

On Mon, Aug 11, 2014 at 10:40:38PM +0800, Li Xi wrote:
> > But since you've been arguing that the project id should get preserved
> > across renames, they can evade quota usage by doing:
> >
> >          touch /product/mail/huge_file
> >          mv  /product/mail/huge_file /product/maps
> I don't really understand why these commands can evade project quota
> since:
> 1) A newly created file will inherit project ID from its parent inode.
> 2) Project ID will be preserved across renames
> 3) Project quota won't be transfered unless its project ID is changed.
> 4) Only root user has the right to change project ID.
> The rule 2) and 3) are just the same sematics with UID/GID quotas.
> So, becasue of rule 1), after 'touch /product/mail/huge_file', the project
> ID of 'huge_file' is 'mail', and its usage is accouted as project 'mail'.
> Even we do 'mv /product/mail/huge_file /product/maps', because
> of rule 2), there is no project ID updating and no quota transfer. Since
> so, the project quota of file 'huge_file' is always accounted as 'mail',
> from the first beginning to the end. And that is why I think project quota
> of 'mail' can't be evaded in this way.

Yes, and *that* is the quota evasion.  There is no difference in terms
of who ends up owning the quota between:

     touch /product/mail/huge_file
     mv /product/mail/huge_file /product/maps

and

    touch /product/maps/huge_file
    chgrp mail /product/maps/huge_file

Either way, a file that is storing maps information (that is why it is
in /product/maps/huge_file) ends up getting accounted against the mail
product's quota.

So if you say, ok, we're using project quota, we won't allow:

    chproject mail /product/maps/huge_file

But then the user can just do this instead:

     touch /product/mail/huge_file
     mv /product/mail/huge_file /product/maps

This is why we MUST NOT allow the rename, or force the project quota
to change when you move the inode to a different directory hierarchy
owned by a different project.

					- Ted