Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1473065ybi; Fri, 14 Jun 2019 15:50:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqw/Pq90EJLfwQEt8JEy/m9uXOqg35xcgSAULcdsGRG79rvefaXicQlJ02mTyJis2uK8/JP1 X-Received: by 2002:a17:90a:9289:: with SMTP id n9mr13521430pjo.35.1560552611646; Fri, 14 Jun 2019 15:50:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560552611; cv=none; d=google.com; s=arc-20160816; b=zIWpdttxrbSsWtqPncnKwVuASBtuzWazrQzxKCY4BH/y7AS4/xaGHaOIwhSp3jqIHw D4byiznx3h8x5daHLtJhvq7LWdeULsdBXLH9HwO6gEsXiAGYt9s9HyE/YhsL7GqmzHEG JHPAOH07NIKRVzlTANF8Dk6uz6rIjoV2DKsTc8YEw/8EbhTKJx6OqtXvso6dK/VLTcBj 2Us1H8KVM8P+IpCYlhT3d0PMFURqxFt9rDZQpyZmDfuznT3hQZz9uh/Jw/miLDh7ys3m fva+vpS8kTQ/CC+6ugwkPQpae1kvOXr+2NFFdUfbZ0W8Tur6M/UBvoQkfRL3SNeRNqYY G8+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=kbewMGFsf3NG5S/ececI7qiEzOBlHXSz9tPVMeP272g=; b=TrX/ChYQE/i6vDT3ZpJQVTAqadDhN20/oG5ZEXUzV2l4T5sOXSHAfiivbhJcHCP2me g2FdNoVNHr7V5zr4sIhJ1sDVVvufjFHq6NIHSGN4J+RReBygm6fMFZLj4o5pRvDASBdl D0E2MkRWH+C87HQRSOx1zQR3RBJiKAn0UgyrfCEUhE5aBnNbZAEA1uTHRU/ci5a9FHTw Z/NtsuDeSCl91KSopKdBQnpq+ZYQb7ch45qXBn90ONcLKTv7DxSe8p0acHUu49Y5CLMp ddzBVVWsYjFVxWRGCAIWIv+vgPPVL9EwEFpvzMp7AHS4+BAKU+QkWMJTcH5y7A3o2td9 TbtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bqyaGulc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z14si3674885pgc.581.2019.06.14.15.49.57; Fri, 14 Jun 2019 15:50:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bqyaGulc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726419AbfFNWtm (ORCPT + 99 others); Fri, 14 Jun 2019 18:49:42 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:40316 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725868AbfFNWtm (ORCPT ); Fri, 14 Jun 2019 18:49:42 -0400 Received: by mail-io1-f68.google.com with SMTP id n5so9156293ioc.7; Fri, 14 Jun 2019 15:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kbewMGFsf3NG5S/ececI7qiEzOBlHXSz9tPVMeP272g=; b=bqyaGulcLlNgacvRyHfISjHg6dWjzEmwltdTXycBch8Y4oCSdOq7s2nUHqFXYTwDoB uBqFbc1NnVFS/tR6NRwD/PK3suBu7MwY9MSTw2swwsSzd/1JlzBFhEF0p8pLBvy4z/sE BkCkDhTgj+3ozKLHavrVqE693cvR+6G2N+tRH34OhwRZEOZBirPbQzKlvYpTirrlHgSO IY2cpLcm27o2iOkem5Nba3n8acmyVTs2bAiiI5hPgwru2TvkM1jQU8dcPX7vwNnAsLs3 JgtsN/pOH6GoA15YanxcmIPJNCPZy/GoX1gE4hDgE4hu2lLZriJfgb7MWu2nEis0ebak w/0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kbewMGFsf3NG5S/ececI7qiEzOBlHXSz9tPVMeP272g=; b=hY7yNivUnzPnwvNvofxK7fMsxKxvsG+FrKZyYQGT//ZthGIsLgLuqhOdR9N8u5o6x4 T1fAzjHFx4CJiIzSBTPkJJGcOC9tznNzP4NBM+7VlaDSppWLZOxYW5sgskURyOioS+2d cb4XMkYMNKwGkBcJpuOd04SW2ZdaZEFHBNF0hp2ApOid9KEI4qLMp97wpfJR6SoQK59w qKZuCpo42f93UDMmeSwcTfLfpwaQokM2RKa/g36YuBZqDY2HRJKYX0w0GEOE7B4lTewk YUbduI8MvQBc2bB+KUu0iCik06jhrRTBdUH0pYmdryNpYgJUGkvWm+pyLDuvGnJ9Kgkf nMnw== X-Gm-Message-State: APjAAAUYLgSSyNh32kPa60oh3C5b1OLm9GnTvWg7UkglfK7Wppy7Oeno sk11i+pYYnEAGG1jKGrJ3US2hQB8CdDuRmik0pY= X-Received: by 2002:a5e:8618:: with SMTP id z24mr63324703ioj.174.1560552581128; Fri, 14 Jun 2019 15:49:41 -0700 (PDT) MIME-Version: 1.0 References: <20180429104412.22445-1-christian.brauner@ubuntu.com> <20180429104412.22445-3-christian.brauner@ubuntu.com> In-Reply-To: <20180429104412.22445-3-christian.brauner@ubuntu.com> From: Dmitry Torokhov Date: Fri, 14 Jun 2019 15:49:30 -0700 Message-ID: Subject: Re: [PATCH net-next 2/2 v5] netns: restrict uevents To: Christian Brauner Cc: "Eric W. Biederman" , "David S. Miller" , netdev , lkml , avagin@virtuozzo.com, ktkhai@virtuozzo.com, "Serge E. Hallyn" , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Christian, On Sun, Apr 29, 2018 at 3:45 AM Christian Brauner wrote: > > commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces") >abhishekbh@google.com > enabled sending hotplug events into all network namespaces back in 2010. > Over time the set of uevents that get sent into all network namespaces has > shrunk. We have now reached the point where hotplug events for all devices > that carry a namespace tag are filtered according to that namespace. > Specifically, they are filtered whenever the namespace tag of the kobject > does not match the namespace tag of the netlink socket. > Currently, only network devices carry namespace tags (i.e. network > namespace tags). Hence, uevents for network devices only show up in the > network namespace such devices are created in or moved to. > > However, any uevent for a kobject that does not have a namespace tag > associated with it will not be filtered and we will broadcast it into all > network namespaces. This behavior stopped making sense when user namespaces > were introduced. > > This patch simplifies and fixes couple of things: > - Split codepath for sending uevents by kobject namespace tags: > 1. Untagged kobjects - uevent_net_broadcast_untagged(): > Untagged kobjects will be broadcast into all uevent sockets recorded > in uevent_sock_list, i.e. into all network namespacs owned by the > intial user namespace. > 2. Tagged kobjects - uevent_net_broadcast_tagged(): > Tagged kobjects will only be broadcast into the network namespace they > were tagged with. > Handling of tagged kobjects in 2. does not cause any semantic changes. > This is just splitting out the filtering logic that was handled by > kobj_bcast_filter() before. > Handling of untagged kobjects in 1. will cause a semantic change. The > reasons why this is needed and ok have been discussed in [1]. Here is a > short summary: > - Userspace ignores uevents from network namespaces that are not owned by > the intial user namespace: > Uevents are filtered by userspace in a user namespace because the > received uid != 0. Instead the uid associated with the event will be > 65534 == "nobody" because the global root uid is not mapped. > This means we can safely and without introducing regressions modify the > kernel to not send uevents into all network namespaces whose owning > user namespace is not the initial user namespace because we know that > userspace will ignore the message because of the uid anyway. > I have a) verified that is is true for every udev implementation out > there b) that this behavior has been present in all udev > implementations from the very beginning. Unfortunately udev is not the only consumer of uevents, for example on Android there is healthd that also consumes uevents, and this particular change broke Android running in a container on Chrome OS. Can this be reverted? Or, if we want to keep this, how can containers that use separate user namespace still listen to uevents? Thanks. -- Dmitry