netdev - Re: [RFC] per-containers tcp buffer limitation

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:	Thu, 25 Aug 2011 14:55:39 +0200
From:	Daniel Wagner <wagi@...om.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Glauber Costa <glommer@...allels.com>,
	Linux Containers <containers@...ts.osdl.org>,
	netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [RFC] per-containers tcp buffer limitation

Hi

On 08/25/2011 04:16 AM, Eric W. Biederman wrote:
> KAMEZAWA Hiroyuki<kamezawa.hiroyu@...fujitsu.com>  writes:
>
>> On Wed, 24 Aug 2011 22:28:59 -0300
>> Glauber Costa<glommer@...allels.com>  wrote:
>>
>>> On 08/24/2011 09:35 PM, Eric W. Biederman wrote:
>>>> Glauber Costa<glommer@...allels.com>   writes:
>>> Hi Eric,
>>>
>>> Thanks for your attention.
>>>
>>> So, this that you propose was my first implementation. I ended up
>>> throwing it away after playing with it for a while.
>>>
>>> One of the first problems that arise from that, is that the sysctls are
>>> a tunable visible from inside the container. Those limits, however, are
>>> to be set from the outside world. The code is not much better than that
>>> either, and instead of creating new cgroup structures and linking them
>>> to the protocol, we end up doing it for net ns. We end up increasing
>>> structures just the same...
>
> You don't need to add a netns member to sockets.
>
> But I do agree that there are odd permission issues with using the
> existing sysctls and making them per namespace.
>
> However almost everything I have seen with memory limits I have found
> very strange.  They all seem like a very bad version of disabling memory
> over commits.

Please apply the same rules for not cursing my family no further then 
the 3rd generation for my idea:

I'd like to solve a use case where it is necessary to count all bytes 
transmitted and received by an application [1]. So far I have found two 
unsatisfying solution for it. The first one is to hook into libc and 
count the bytes there. I don't think I have to say I don't like this.

The second idea was to use the trick Google has used for Android [2]. 
They add a hook into __sock_sendmsg and __sock_recvmsg and then count 
the bytes per UID. To get this working all application have to use an 
unique UID. So not very nice either.

After reading a bit up on cgroup I think that would be the right place 
to count the traffic. Unfortunately, with net_cls I can count the 
outgoing traffic but not the incoming one. If I understood Glauber 
approach correctly adding some statistic counters would be easy to do. 
Of course I don't know the impact of this.

thanks,
daniel

[1] 
http://lists.freedesktop.org/archives/systemd-devel/2011-August/003093.html

[2] 
http://xf.iksaif.net/dev/android/android-2.6.29-to-2.6.32/0083-uidstat-Adding-uid-stat-driver-to-collect-network-st.patch
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html