All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Michael J Coss <michael.coss@alcatel-lucent.com>
Cc: davem@davemloft.net, linux-kernel@vger.kernel.org,
	containers@lists.linuxcontainers.org, serge.hallyn@ubuntu.com,
	stgraber@ubuntu.com
Subject: Re: [PATCH 0/3] kobject: support namespace aware udev
Date: Wed, 9 Sep 2015 13:09:35 -0700	[thread overview]
Message-ID: <20150909200935.GB9328@kroah.com> (raw)
In-Reply-To: <55F082F9.7050305@alcatel-lucent.com>

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

  reply	other threads:[~2015-09-09 20:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-09  2:10 [PATCH 0/3] kobject: support namespace aware udev Michael J. Coss
2015-09-09  2:10 ` [PATCH 1/3] lib/kobject_uevent.c: disable broadcast of uevents to other namespaces Michael J. Coss
2015-09-11  0:36   ` Eric W. Biederman
2015-09-11 18:21     ` Michael J Coss
     [not found]   ` <51c185b6fa89f0b8e9e7dcaffb3c21c975c84302.1441762578.git.michael.coss-cfy2TCaE7SFv+uJa97DSA9BPR1lH4CV8@public.gmane.org>
2015-10-02 17:40     ` Oren Laadan
2015-09-09  2:10 ` [PATCH 2/3] lib/kobject_uevent.c: add uevent forwarding function Michael J. Coss
2015-09-09  3:55   ` Greg KH
     [not found]     ` <20150909035527.GB5153-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-09-09 19:24       ` Michael J Coss
2015-09-09 19:24         ` Michael J Coss
     [not found]         ` <55F0875C.6060108-cfy2TCaE7SFv+uJa97DSA9BPR1lH4CV8@public.gmane.org>
2015-09-09 20:11           ` Greg KH
2015-09-09 20:11             ` Greg KH
     [not found]             ` <20150909201123.GC9328-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-09-10  5:43               ` Amir Goldstein
2015-09-10  5:43                 ` Amir Goldstein
     [not found]                 ` <CAA2m6vcnUz4EeS-FH2P=GjKSquXit=j1NE5Yut8_baLA+TvjJA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-10  5:58                   ` Greg KH
2015-09-10  5:58                     ` Greg KH
2015-09-11  0:54   ` Eric W. Biederman
2015-09-11 18:43     ` [COMMERCIAL] " Michael J Coss
     [not found]   ` <3456750fe7a5a5eb709e315618facf5704cc1885.1441762578.git.michael.coss-cfy2TCaE7SFv+uJa97DSA9BPR1lH4CV8@public.gmane.org>
2015-10-02 18:00     ` Oren Laadan
     [not found]       ` <CAA4jN2br76atf9UuOhJVcoQPZ6GMN91Mk1GsoXcVFC-eFvFafA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-14  3:40         ` Oren Laadan
2015-09-09  2:10 ` [PATCH 3/3] net/udevns: Netlink module to forward uevent to containers Michael J. Coss
2015-09-11  1:05   ` Eric W. Biederman
2015-09-11 19:01     ` Michael J Coss
2015-09-09  3:54 ` [PATCH 0/3] kobject: support namespace aware udev Greg KH
2015-09-09 19:05   ` Michael J Coss
2015-09-09 20:09     ` Greg KH [this message]
2015-09-09 20:16       ` Michael J Coss
2015-09-09 20:28         ` Greg KH
2015-09-09 20:55           ` [COMMERCIAL] " Michael J Coss
2015-09-10  5:21             ` Greg KH
     [not found] ` <cover.1441762578.git.michael.coss-cfy2TCaE7SFv+uJa97DSA9BPR1lH4CV8@public.gmane.org>
2015-09-09 18:53   ` [PATCH 1/3] lib/kobject_uevent.c: disable broadcast of uevents to other namespaces Michael J. Coss
2015-09-09 18:53   ` [PATCH 2/3] lib/kobject_uevent.c: add uevent forwarding function Michael J. Coss
2015-09-09 18:53   ` [PATCH 3/3] net/udevns: Netlink module to forward uevent to containers Michael J. Coss
2015-09-09 18:53 [PATCH 0/3] kobject: support namespace aware udev Michael J. Coss

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150909200935.GB9328@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=containers@lists.linuxcontainers.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.coss@alcatel-lucent.com \
    --cc=serge.hallyn@ubuntu.com \
    --cc=stgraber@ubuntu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.