linux-ext4 - Re: container disk quota

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]

Date:	Sat, 02 Jun 2012 13:42:18 +0800
From:	Jeff Liu <jeff.liu@...cle.com>
To:	Jan Kara <jack@...e.cz>
CC:	containers@...ts.linux-foundation.org, cgroups@...r.kernel.org,
	glommer@...allels.com, daniel.lezcano@...e.fr, tytso@....edu,
	bpm@....com, chris.mason@...cle.com, hch@...radead.org,
	christopher.jones@...cle.com, david@...morbit.com,
	tinguely@....com, tm@....ma, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: container disk quota

Hi Jan,

On 06/01/2012 11:54 PM, Jan Kara wrote:

>   Hello,
> 
> On Wed 30-05-12 22:58:54, jeff.liu@...cle.com wrote:
>> According to glauber's comments regarding container disk quota, it should be binded to mount
>> namespace rather than cgroup.
>>
>> Per my try out, it works just fine by combining with userland quota utilitly in this way.
>> However, they are something has to be done at user tools too IMHO.
>>
>> Currently, the patchset is in very initial phase, I'd like to post it early to seek more
>> feedbacks from you guys.
>>
>> Hopefully I can clarify my ideas clearly.
>   So what I miss in this introductory email is some highlevel description
> like what is the desired functionality you try to implement and what is it
> good for. Looking at the examples below, it seems you want to be able to
> set quota limits for namespace-uid (and also namespace-gid???) pairs, am I
> right?

Sorry for lacking the high level descriptions.

The main idea is to introduce a quota mechanism to let container make use of it like VFS quota/quota
tools as transparent as possible.

However our general quota subsystem works with one global hashtable list, and it based on superblock
and global UID/PID for those accounting, and looks that's not convenient to support container quota
without much changes IMHO.

The current opinion is to bind it to mount namespace, since container can be setup through CLONE_MNTNS to
have its private mount tree.

> 
>   If yes, then I would like to understand one thing: When writing to a
> file, used space is accounted to the owner of the file. Now how do we
> determine owning namespace?

That's also the main point I am concerned.
It think the latest USER_NS feature would be got involved in.
And also, we can detect the mount namespace by inferring it from processes context.  We only bill those
space operations if themount namespace is quota desired.

Here has another issue, when we doing quota info initialization on a mount namespace?
In my current implementation, it is simply implemented by checking if mount namespace was cloned out,
and do quotactl(2) if the input device is "rootfs",  or just checking if the mount namespace is not the
initial global one.
quotactl(2) will be processed if meet either above conditions, and space operations will be counted if
the desired UID/GID dquot could be searched.

> Do you implicitely assume that only processes
> from one namespace will be able to access the file?

All processes could access the file, but only those space operation of processes resides in the mount
namespace with quota setup will be billed.

Thanks,
-Jeff

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