[lxc-devel] [PATCH] Use container specific domain socket name

Daniel Lezcano daniel.lezcano at free.fr
Mon Apr 15 09:14:28 UTC 2013


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.

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