[Devel] Re: [RFC][PATCH] IP address restricting cgroup subsystem
Li Zefan
lizf at cn.fujitsu.com
Wed Jan 7 01:33:49 PST 2009
Grzegorz Nosek wrote:
> On śro, sty 07, 2009 at 04:36:35 +0800, Li Zefan wrote:
>> Grzegorz Nosek wrote:
>>>>> IP addresses are write-once (via /cgroup/.../ipaddr.ipv4 in dotted-quad
>>>> Why they should be write-once ?
>>> No real (technical) reason. Making it read-write would be fine with me.
>>> I wanted to make the restriction a one-way road but I guess I can police
>>> that in userspace (simply don't write anything to the file twice).
>>>
>> But seems the patch makes it impossible to re-allow a restricted task to
>> be binded to INADDR_ANY.
>
> Yes, my goal is to disallow that but I don't insist to do that in the
> kernel (I'm not currently planning to let untrusted root loose in a
> container).
>
>> Firstly, is inheritance necessary ?
>
> It would be nice to have when the container's root is untrusted but
> might want to subdivide the container's cgroup for other purposes.
> Without inheritance, they would be able to circumvent the IP address
> restriction. One could argue that a full untrusted-root container would
> need a proper network namespace anyway (and giving CAP_SYS_ADMIN there
> is probably a very bad idea), but still, I'd feel uneasy.
>
>> If yes, then how about:
>>
>> The root cgroup is read-only, so the tasks in it always bind to INADDR_ANY.
>> For other cgroups, write is allowed only if it has no children and the
>> parent is INADDR_ANY.
>
> Yes, I like that. Will update the patch. I assume that I must check
> list_empty(&cgroup->children)?
Yes.
> Should I use cgroup_lock()/cgroup_unlock()
Yes.
> or other locking? I think it will be safe to do without locks but would
> rather get some expert advice.
>
No. Without locks, it races with mkdir.
=============
//cgroup_lock();
if (list_empty(&cgrp->children) &&
parent->ipv4_addr == INADDR_ANY)
<--- mkdir()
ipcgroup->ipv4_addr = new_addr;
//cgroup_unlock();
==============
In the above case, ipcgroup->ipv4_addr = new_addr,
but child_cgroup->ipv4_addr == INADDR_ANY, which is not expected.
> Thanks a lot for your comments.
>
> Best regards,
> Grzegorz Nosek
>
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list