linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Christian Brauner <christian.brauner@canonical.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	avagin@virtuozzo.com, ktkhai@virtuozzo.com,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH net-next 2/2 v5] netns: restrict uevents
Date: Sun, 16 Jun 2019 10:14:32 -0700	[thread overview]
Message-ID: <CAKdAkRT98DmxCHPL+1+COinSEDU0_87GMDL6ZiQEiBJSd286yw@mail.gmail.com> (raw)
In-Reply-To: <20190616165027.prdbshnipwphqtis@gmail.com>

Hi Christian,

On Sun, Jun 16, 2019 at 9:50 AM Christian Brauner
<christian.brauner@canonical.com> wrote:
>
> Hey Dmitry,
>
> Crostini on ChromeOS is making heavy use of this patchset and of LXD. So
> reverting this almost 1.5 years after the fact will regress all of
> Google's ChromeOS Crostini users, and all LXD/LXC users.
>
> LXD and Crostini by using LXD (through Concierge/Tremplin etc. [2]) are
> using this whole series e.g. when hotplugging usb devices into the
> container.
>
> When a usb hotplug happens, LXD will receive the relevant uevent and
> will forward it to the container. Any process listening on a uevent
> socket inside the container will now be able to see it.
>
> Now, to talk briefly about solutions:
> From what I gather from talking to the ChromeOS guys and from your
> ChromeOS bugtracker and recent patchsets to ARC you are moving your
> Android workloads into Crostini? So like Eric said this seems like a new
> feature you're implementing.

No, I am talking about ARC, not Crostini here.

>
> If you need to be able to listen to uevents inside of a user namespace
> and plan on using Crostini going forward then you can have Crostini
> forward battery uevents to the container. The logic for doing this can
> be found in the LXD codebase (cf. [3]). It's pretty simple. If you want
> to go this route I'm happy to guide you. :)
> Note, both options are a version of what Eric suggested in his last
> paragraph!
>
> What astonishes me is that healthd couldn't have possibly received
> battery uevents for a long time even if Android already was run in user
> namespaces prior to the new feature you're working on and the healthd I
> see in master is not even using uevents anymore (cf. [8]) but rather is
> using sysfs it seems. :)
> Before that healthd was using (cf. [7])
>
> uevent_kernel_multicast_recv()
> |
> -> uevent_kernel_multicast_uid_recv
>
> the latter containing the check
>
> if (cred->uid != 0) {
>     /* ignoring netlink message from non-root user */
>     goto out;
> }
>
> Before my patchset here the uevents sent out came with cred->uid == INVALID_UID
> and so healthd never received those events until very recently.

I see. OK, let me try digging into this to figure out what exactly changed.

Thanks.

-- 
Dmitry

  reply	other threads:[~2019-06-16 17:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-29 10:44 [PATCH net-next 0/2 v5] netns: uevent filtering Christian Brauner
2018-04-29 10:44 ` [PATCH net-next 1/2 v5] uevent: add alloc_uevent_skb() helper Christian Brauner
2018-04-29 10:44 ` [PATCH net-next 2/2 v5] netns: restrict uevents Christian Brauner
2019-06-14 22:49   ` Dmitry Torokhov
2019-06-16 11:50     ` Eric W. Biederman
2019-06-16 16:50       ` Christian Brauner
2019-06-16 17:14         ` Dmitry Torokhov [this message]
2019-06-16 16:50       ` Dmitry Torokhov
2018-04-30 15:55 ` [PATCH net-next 0/2 v5] netns: uevent filtering Eric W. Biederman
2018-05-01 14:23   ` David Miller

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=CAKdAkRT98DmxCHPL+1+COinSEDU0_87GMDL6ZiQEiBJSd286yw@mail.gmail.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=avagin@virtuozzo.com \
    --cc=christian.brauner@canonical.com \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=serge@hallyn.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).