<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 25, 2013 at 11:13 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">Quoting Michael J Coss (<a href="mailto:michael.coss@alcatel-lucent.com">michael.coss@alcatel-lucent.com</a>):<br>

> I've been looking at this problem for some time to help solve my very<br>
> specific use case.   In our case we are using containers to provide<br>
> individual "desktops" to a number of users.  We want the desktop to run<br>
> X, and bind and unbind a display, keyboard, mouse to that X server<br>
> running in a particular container, and not be able to grab anyone elses<br>
> keyboard, mouse or display unless granted specific access to that from<br>
> the owern.  To that end, I started worked on a udev solution.  I<br>
> understand that most containers don't/won't run udev.  And systemd won't<br>
> even start udev if the container doesn't have the mknod capability which<br>
> is a kinda odd cookie but I digress.<br>
><br>
> Currently the kernel effectively broadcasts uevents to all network<br>
> namespaces, and this is an issue.  I don't want container A to see<br>
> container B's events.  It should see only what the admin has set for the<br>
> policy for that container.  This policy should be handled on the host<br>
> for the containers in userspace.  This deamon can get the events, and<br>
> then forward to the appropriate container(s) those events that are<br>
> pertinent, and disregard the rest.  To accomplish this, I had to change<br>
> the broadcast mechanism, and then provide a forwarding mechanism to<br>
> specific network namespaces.<br>
><br>
> Back in the day, that would have been sufficient.  Udev running in the<br>
> container would have gotten the add event, and created the appropriate<br>
> devices and symlinks, and then cleaned up on remove/change events.  With<br>
> the introduction of devtmpfs, udev no longer actually creates the device<br>
> nodes.  It just handles links and name changes.   So, I'm still left<br>
> with needing to create/manage devtmpfs or some other solution.  This<br>
> leads me down the path of virtualizing devtmpfs.  I've been fooling<br>
> around with FUSE, to basically mirror the host /dev (filtered<br>
<br>
</div></div>Rather than using FUSE, I'd recommend looking into doing it the same<br>
way as the devpts fs.  Might not work out (or be rejected) in the end,<br>
but at first glance it seems the right way to handle it.  So each new<br>
instance mount starts empty, changes in one are not reflected in<br>
another, but new devices which the kernel later creates may (subject<br>
to device cgroup of the process which mounted it?) be created in the<br>
new instances.<br></blockquote><div><br></div><div>I was thinking it makes sense to tie unique instances of devtmpfs sb to userns.</div><div>If not for any other reason, for the fact that any mount sb already has the knowledge</div>
<div>of the userns that mounted it.</div><div>But also, I think devtmpfs needs to be userns friendly, so it can safely get the FS_USERNS_DEV_MOUNT flag.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=""><div class="h5"><br>
> appropriately), but there are many ugly security, and implementation<br>
> details that look bad to me.  I have been kicking around the notion that<br>
> the device cgroup might provide the list of "acceptable" devices, and<br>
> construct a filter/view for devtmpfs based on that.<br>
><br>
> I do have these changes working on a mostly stock 3.10 kernel,  the<br>
> kernel changes are pretty small, and the deamon does a pretty minimal<br>
> filtering mostly to demonstrate functionality.  It does assume that the<br>
> containers are running in a separate network namespace, but that's about it.<br>
><br>
> Of course, that still leaves you with sysfs needing similar treatment.<br>
><br>
> ---Michael J Coss<br>
><br>
> ------------------------------------------------------------------------------<br>
> October Webinars: Code for Performance<br>
> Free Intel webinars can help you accelerate application performance.<br>
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from<br>
> the latest Intel processors and coprocessors. See abstracts and register ><br>
> <a href="http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk</a><br>
> _______________________________________________<br>
> Lxc-devel mailing list<br>
> <a href="mailto:Lxc-devel@lists.sourceforge.net">Lxc-devel@lists.sourceforge.net</a><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/lxc-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/lxc-devel</a><br>
<br>
------------------------------------------------------------------------------<br>
October Webinars: Code for Performance<br>
Free Intel webinars can help you accelerate application performance.<br>
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from<br>
the latest Intel processors and coprocessors. See abstracts and register ><br>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Lxc-devel mailing list<br>
<a href="mailto:Lxc-devel@lists.sourceforge.net">Lxc-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/lxc-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/lxc-devel</a><br>
</div></div></blockquote></div><br></div></div>