<div dir="ltr">Hi there,<div><br></div><div>What about using AF_INET but binding a restricted port while adding a new field to the message? As an example we can start to create a hmac (or something like that) per container in the creation time and save that into LXCPATH/CONTAINERNAME/hmac. Then both client (can add that value to message) and server (can read from filesystem to check authenticity of the file) can use it.<br>

</div><div><br></div><div style>By binding a restricted port we guarantee that regular users cannot sniff the traffic and by using the filesystem permissions we provide the desired separation?</div><div style><br></div><div style>

<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 16, 2013 at 11:25 AM, Serge Hallyn <span dir="ltr"><<a href="mailto:serge.hallyn@ubuntu.com" target="_blank">serge.hallyn@ubuntu.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Quoting Dwight Engen (<a href="mailto:dwight.engen@oracle.com">dwight.engen@oracle.com</a>):<br>


> On Tue, 16 Apr 2013 08:52:56 -0500<br>
> Serge Hallyn <<a href="mailto:serge.hallyn@ubuntu.com">serge.hallyn@ubuntu.com</a>> wrote:<br>
><br>
> > Quoting S.Çağlar Onur (<a href="mailto:caglar@10ur.org">caglar@10ur.org</a>):<br>
> > > Hi Serge,<br>
> > ><br>
> > > I was just following your lead as you said you don't wan't any long<br>
> > > running monitor daemon :)<br>
> ><br>
> > Yup, at this point I"m going for the least bad solution.  (since the<br>
> > best solution, multicast af_unix, isn't possible :)<br>
> ><br>
> > > Also I'm not sure how does that daemon is going to help<br>
> > > starting multiple containers concurrently using only API. I'm<br>
> > > guessing the first request will cause that daemon to start and it<br>
> > > will never end unless specifically told it to shutdown?<br>
> ><br>
> > So basically,<br>
> ><br>
> >   c1  -                                --> m1<br>
> >         \                             /<br>
> >   c2  ----->  "\0$lxcpath" Daemon -------> m2<br>
> >         /                             \<br>
> >   c3  -/                               --> m3<br>
> ><br>
> > m1 is the first lxc-monitor someone started.  It sees that<br>
> > "\0$lxcpath" is not bound, so fires off a long-running daemon<br>
> > listening for events on "\0$lxcpath", and doing listen/accept at<br>
> > "\0$lxcpath.M".  Then m1 connects to to that daemon on "\0$lxcpath.M"<br>
> > and listens for events.  m2 starts, connects to "\0$lxcpath.M", and<br>
> > listens for events.  m3. does the same.  m1 exits, but the daemon<br>
> > continues.<br>
><br>
> The daemon could keep track of how many monitors are connected and<br>
> exit when the count drops to zero (after waiting some small amount of<br>
> time for a new monitor connection which also handles the initial<br>
> startup case).<br>
<br>
</div></div>Yup that sounds good :)<br>
<div class="im"><br>
> This daemon isn't queuing right? So we define that when there is no<br>
> monitor connected, all events are dropped.<br>
<br>
</div>Yup, as is the case now.<br>
<br>
Anyone want to code a prototype?<br>
<span class="HOEnZb"><font color="#888888"><br>
-serge<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>S.Çağlar Onur <<a href="mailto:caglar@10ur.org">caglar@10ur.org</a>>
</div>