On Thu, Feb 05, 2015 at 05:38:15PM +0100, Jan Kara wrote: > Hello, > > > 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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
