[lxc-devel] [PATCH] Use container specific domain socket name
Daniel Lezcano
daniel.lezcano at free.fr
Mon Apr 15 20:29:09 UTC 2013
On 04/15/2013 07:18 PM, Serge Hallyn wrote:
> Quoting Daniel Lezcano (daniel.lezcano at free.fr):
>> On 04/15/2013 07:53 AM, S.Çağlar Onur wrote:
>>> Hi Daniel,
>>>
>>>
>>> On Sun, Apr 14, 2013 at 4:42 PM, Daniel Lezcano
>>> <daniel.lezcano at free.fr <mailto:daniel.lezcano at free.fr>> wrote:
>>>
>>> On 04/14/2013 09:56 PM, S.Çağlar Onur wrote:
>>> > Hi all,
>>> >
>>> > I had some free time today so I tried to implement something using
>>> > AF_INET messages over loopback broadcast address. I'm not including
>>> > the patch here because gmail web interface damages it and that's
>>> what
>>> > I use right now so please use [1] to see it.
>>> >
>>> > I'm sending it to get your feedback and will submit it to list
>>> if you
>>> > are OK with that approach.
>>> >
>>> > P.S: I used 51423 as the port but of course it can be changed
>>> > accordingly.
>>> >
>>> > [1]
>>> >
>>> https://github.com/caglar10ur/lxc-upstream/commit/123b20e2945ed2b4bc9e6e27b9ef398ec8fcae40.patch
>>>
>>> Thanks for this code !
>>>
>>> It sounds like the approach seems ok. My concern is the same than
>>> Serge,
>>> what can we do to ensure an event was sent by a container ?
>>>
>>> We don't want someone to send fake events via UDP. We can't tolerate a
>>> simple program messing a container supervisor and all the containers
>>> (running an OS instance).
>>>
>>> Assuming an user, which is not root, can't build an IP packet, we can
>>> rely on the IP identification number to detect fake packets, no ?
>>>
>>>
>>> I'm not sure about the right answer of that question. I was under the
>>> impression that we are safe since kernel only allows root user to send
>>> broadcast packages over loopback interface but I might
>>> be completely wrong.
>> I don't find a confirmation about this anywhere. Do you have a pointer ?
>> If it is the case, then that's cool because we are safe on this side.
> Though since we want unprivileged container use, I don't particularly
> like that.
Yes, but I thought we could have add permission to create such socket,
but anyway...
> That's another reason I was hoping to stick with AF_UNIX. Then we can
> have a monitor socket per lxcpath (/var/lib/lxc, /home/serge/lxcbase,
> etc).
It seems af_unix multicast socket is proposed again to netdev@
http://lkml.indiana.edu/hypermail/linux/kernel/1202.2/01627.html
I did not followed the entire thread but if it is merged that could be
worth investigate this solution.
> One of the funky solutiosn I was considering was that the first person
> to run lxc-monitor - who has wwrite access to the lxcpath - would simply
> cause a long-running monitor daemon to start, creating the unix socket
> and listening+accepting and forking of handlers. (lxc-monitor --end
> would kill the listening handler if we wanted, though that should be
> so lightweight as to not matter)
>
>> Is your code tested ? I mean, did you validate monitoring the events
>> works with this approach ?
>>
>> Thanks
>> -- Daniel
>>
More information about the lxc-devel
mailing list