[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAPTn0cDSyvA15k+3BGgWtG2hfrS0zkb75=NYhfgPt5pvANTMCg@mail.gmail.com>
Date: Mon, 11 Aug 2014 08:06:41 +0800
From: Li Xi <pkuelelixi@...il.com>
To: "Theodore Ts'o" <tytso@....edu>
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
> This being said, for this particular use case, I'm not entirely sure
> why you can't just create separate groups for each project, and then
> let group inheritance take care of things:
>
> mkdir top-level
> chgrp project1 top-level
> chmod g+s top-level
>
> Now all of the files created in top-level will be accounted in
> project1's quota.
>
> If the answer is that it's too easy to evade quota controls by using
> the "chgrp" command, note that if you are going to allow users to mv
> files around, they can easily evade the project quota anyway, by
> creating the file in top-level dirctory of project2, and then mv'ing
> it into the top-level directory of project1.
Yeah, we don't want common users to change the project ID of thier
files, so setting project is only allowed for administrator in this
implementation. And since project ID of an inode won't be changed
when it is renamed around, common users has no way to evade
project quota.
Regards,
-Li Xi
--
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