lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20150205210501.GR4251@dastard> Date: Fri, 6 Feb 2015 08:05:01 +1100 From: Dave Chinner <david@...morbit.com> To: Jan Kara <jack@...e.cz> Cc: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>, Andy Lutomirski <luto@...capital.net>, Li Xi <pkuelelixi@...il.com>, Linux FS Devel <linux-fsdevel@...r.kernel.org>, "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>, Linux API <linux-api@...r.kernel.org>, Theodore Ts'o <tytso@....edu>, Andreas Dilger <adilger@...ger.ca>, Al Viro <viro@...iv.linux.org.uk>, Christoph Hellwig <hch@...radead.org>, dmonakhov@...nvz.org, "Eric W. Biederman" <ebiederm@...ssion.com> Subject: Re: [v8 4/5] ext4: adds FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support 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@...morbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists