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. 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). 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
