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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140811144535.GD3506@thunk.org>
Date:	Mon, 11 Aug 2014 10:45:35 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Li Xi <pkuelelixi@...il.com>
Cc:	Shuichi Ihara <sihara@....com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"hch@...radead.org" <hch@...radead.org>, Jan Kara <jack@...e.cz>,
	Andreas Dilger <adilger@...ger.ca>,
	"Niu, Yawei" <yawei.niu@...el.com>
Subject: Re: [PATCH v2 0/4] quota: add project quota support

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
--
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