On 04/15/2013 07:18 PM, Serge Hallyn wrote: > Quoting Daniel Lezcano (daniel.lezc...@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.lezc...@free.fr <mailto:daniel.lezc...@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 >> ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
