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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 9 Aug 2014 13:24:27 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Li Xi <pkuelelixi@...il.com>
Cc:	linux-fsdevel@...r.kernel.org,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	viro@...iv.linux.org.uk, 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 Sat, Aug 09, 2014 at 10:24:59PM +0800, Li Xi wrote:
> Given the fact that project indentifier is naturally like UID/GID, project ID
> should be managed in the similar way like UID/GID. And that is what people are
> actually doing right now. We already have kuid_t/kgid_t/kprojid_t and a series
> of similar functions for both UIG/GID and project ID. I don't think it is
> necessary to break this kind of self-consistency when we are trying to add
> project quota support. It would be really straightfoward for a new user to
> understand what project ID and project quota means, if we are able to explain
> that project quota has exactly the same semantics with user/group quota.

There is a very big and fundamental difference about project id's
versus user/group id's, and that is that project id's are not first
class objects in the file system.  That is, stat() doesn't understand
them.  Processes do not belong to one (or more) projects, the way they
do for user and group id's.

As a result, project id's are a massive administration nightmare.  You
can't easily see which project a file belongs to, since "ls" and
"stat" has no support for the project id.  So if a file is created in
one directory, the file will inherent that project id from its parent
directory.  Suppose that file is 100 gigabytes, and it chews up most
of the project quota for that project.  Now suppose that file is moved
to some other directory.

How in the world is the administrator supposed to find the file which
is chewing up 100GB of quota?  Find doesn't support project id's
either....

The last time I asked why in the world anyone would want to use this
feature, the only use case that I heard was people who were using
containers, and where the all of the project id's were inside a
chroot.  Hence, any questions I asked about what happens when a file
gets moved out from the hierarchy were hand-waved away, since inside a
chroot, it could never happen.

The question is what are the sane semantics when you don't have the
chroot restriction, and having free-range inodes with project quotas
that can moved all over the file system, seems to me to result in a
not very usable system in the end.

Regards,

						- 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