On Thu, Feb 05, 2015 at 05:38:15PM +0100, Jan Kara wrote:

  Hello,

quoted

Users have *always* been allowed to set the project ID of
their own files. How else are they going to set the project ID on
files they create in random directories so to account them to the
correct project they are working on?

However, you keep making the assumption that project quotas ==
directory subtree quotas.  Project quotas are *not limited* to
directory subtrees - the subtree quota implementation is just an
implementation that *sets the default project ID* on files as they
are created.

e.g. there are production systems out there where project quotas are
used to track home directory space usage rather than user quotas.
This means users can take actions like "this file actually belongs
to project X and it shouldn't be accounted against my home
directory". Users can create their own sub directories that account
everything by default to project X rather than their own home
directory.

Again: project quotas are an *accounting* mechanism, not a security
mechanism.

  OK, but now I got confused ;) So if users can change project ID of files
they own, what's the point of project quotas? If I need to create a file
and project quota doesn't allow me, I just set its project ID to some
random number and I'm done with that...

Sure, but the admin is going to notice those random numbers in the
next quota report they run and then a user is going to get
re-educated with a clue bat.

So are really project quotas just
"advisory" - i.e., all users of a system cooperate so that project X
doesn't use more space than it should (and project quotas make this
cooperation somewhat simpler) or is there something which limits which
project IDs user can set? I didn't find anything...

Not directly.  Project quotas have historically been used in tandem
with user quotas - user quotas cannot be escaped and that puts a
limit on the shenanigans that users can play with project quota.

[ Indeed, Irix only had user and project quotas - it *never* had group
quotas. e.g. when XFS was ported to Linux the project quota inode
was re-purposed for group quotas in 2001:

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-import.git;a=commitdiff;h=749b2bf3ed5ff064efd69370e6b31ea44c4a78a6
]

However, if you have a fileystem system that users can't directly
access (e.g. an NFS server) then you can use project quotas as a
space enforcement mechanism because users can't change the project
ID on the files on the server. We've used the same model with
containers - for the host to be able to use project quotas as space
resource controller, users inside a container must not be able to
change the project ID of a file....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com