From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754140AbbIITFn (ORCPT ); Wed, 9 Sep 2015 15:05:43 -0400 Received: from fr-hpida-esg-02.alcatel-lucent.com ([135.245.210.21]:58349 "EHLO smtp-fr.alcatel-lucent.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750819AbbIITFk (ORCPT ); Wed, 9 Sep 2015 15:05:40 -0400 Subject: Re: [PATCH 0/3] kobject: support namespace aware udev To: Greg KH References: <20150909035400.GA5153@kroah.com> Cc: davem@davemloft.net, linux-kernel@vger.kernel.org, containers@lists.linuxcontainers.org, serge.hallyn@ubuntu.com, stgraber@ubuntu.com From: Michael J Coss X-Enigmail-Draft-Status: N1110 Message-ID: <55F082F9.7050305@alcatel-lucent.com> Date: Wed, 9 Sep 2015 15:05:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150909035400.GA5153@kroah.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. -- ---Michael J Coss