On 9/9/2015 4:09 PM, Greg KH wrote: > On Wed, Sep 09, 2015 at 03:05:29PM -0400, Michael J Coss wrote: >> On 9/8/2015 11:54 PM, Greg KH wrote: >>> On Tue, Sep 08, 2015 at 10:10:27PM -0400, Michael J. Coss wrote: >>>> Currently when a uevent occurs, the event is replicated and sent to every >>>> listener on the kernel netlink socket, ignoring network namespaces >>>> boundaries, >>>> forwarding events to every listener in every network namespace. >>>> >>>> With the expanded use of containers, it would be useful to be able to >>>> regulate this flow of events to specific containers. By restricting >>>> the events to only the host network namespace, it allows for a userspace >>>> program to provide a system wide policy on which events are routed where. >>> Interesting, but why do you need a container to get a uevent at all? >>> What uevents do a container care about? >>> >>> thanks, >>> >>> greg k-h >>> >> In our use case, we run a full desktop inside the container, including >> X. > Ugh, I was worried you were going to say that :( > >> We run the Xserver in headless mode, and forward a uevent to the >> container to allow binding/unbinding of remote keyboard, mice, and >> displays. So I want the add/del keyboard events, add/del mouse events, >> and add/del display events. This is just one use case, I could image >> others. The bottom line is that the current behavior is to broadcast to >> everyone all uevents, and I don't see that as correct as it crosses the >> network namespace boundaries. It seems to me that you would want to >> provide controls as to where you want to forward those uevents, and >> that is not a policy that I believe should be in the kernel but rather >> in user space. > devices are not in namespaces, which is why we don't partition them off > at all. And that's why I really don't want to add this type of > filtering either. It's up to the "master" container/process/whatever to > send uevents to child containers if it really wants to. If we were to > ever have devices bound only to namespaces, then it would make sense to > only send the uevents for those devices to that namespace. > > But as that's never going to happen, I don't want to give people a false > sense of "separation" here that isn't really there at all. > > sorry, > > greg k-h > Agreed that devices are not in namespaces, but the events are, or at least could be. That master is the host, and to do that I want to forward events that the host receives to those individual containers. But since the kernel is broadcasting them, I can't have that policy on the host, and would have to filter on each container. Or I can do as you say and have the master forward events. I don't see this as putting the devices into a namespace, but rather managing devices from the outside and notifying the container of the event. Just like plugging in a monitor to the container.
-- ---Michael J Coss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
