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