Date:	Wed, 9 Sep 2015 16:16:49 -0400
From:	Michael J Coss <michael.coss@...atel-lucent.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	davem@...emloft.net, linux-kernel@...r.kernel.org,
	containers@...ts.linuxcontainers.org, serge.hallyn@...ntu.com,
	stgraber@...ntu.com
Subject: Re: [PATCH 0/3] kobject: support namespace aware udev

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists