Quoting S.Çağlar Onur (cag...@10ur.org): > 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?
But we want regular users to be able to monitor their own containers. Now I suppose we could require an extra netns layer where an unprivileged user must first create a new userns, create a new netns in that, and start containers from there. Then he has privilege over restricted ports in that netns, so he can monitor containers created from there. It also gives a somewhat simple way to provide networking to unprivileged-user-created containers- simply have a privileged init script create the userns+netns for the user, keeping it open, create a NIC in there and hook it into a host bridge (since this init job is privileged on the host), then hand the setns fd to the user (by bind-mounting into a DAC-protected directory like /lxc/ns/$USER/). Now the user can setns into /lxc/ns/$user before running any lxc commands. It's quite different from what I was earlier envisioning, but doable. Disclaimer: I'm groggy this morning, so might be talking sillyness. -serge ------------------------------------------------------------------------------ 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
