From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S965193AbdEONs3 (ORCPT <rfc822;w@1wt.eu>);
        Mon, 15 May 2017 09:48:29 -0400
Received: from shards.monkeyblade.net ([184.105.139.130]:34824 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S934323AbdEONs2 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 15 May 2017 09:48:28 -0400
Date: Mon, 15 May 2017 09:48:23 -0400 (EDT)
Message-Id: <20170515.094823.1069232190223991895.davem@davemloft.net>
To: maheshb@google.com
Cc: gregkh@linuxfoundation.org, mahesh@bandewar.net, mingo@kernel.org,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        ebiederm@xmission.com, keescook@chromium.org, edumazet@google.com
Subject: Re: [PATCH] kmod: don't load module unless req process has
 CAP_SYS_MODULE
From: David Miller <davem@davemloft.net>
In-Reply-To: <CAF2d9jh6zARipRGM92drOjjrpicF6177cnUf=6oHbR9tHX1ObA@mail.gmail.com>
References: <20170512232259.10820-1-mahesh@bandewar.net>
        <20170514104537.GA29323@kroah.com>
        <CAF2d9jh6zARipRGM92drOjjrpicF6177cnUf=6oHbR9tHX1ObA@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 15 May 2017 06:06:56 -0700 (PDT)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v4FDmXNF011562

From: Mahesh Bandewar (महेश बंडेवार) <maheshb@google.com>
Date: Sun, 14 May 2017 19:42:08 -0700

> Any module when loaded gets loaded system-wide as we can't allow
> module loading per-ns. To validate the behavior I was comparing it
> with insmod/modprobe, if that doesn't allow because of lack of this
> capability in default-ns, then this *indirect* method of loading
> module should not allow the same action and the behavior should be
> consistent. So with that logic if userspace asks for a random
> char-device if insmod/modprobe cannot load it, then this method should
> not load it either for the consistency, right?

A lot of us worry that the are decades of precedence for the current
behavior.

If the user asks for bridge statistics and the bridge module isn't
loaded, it does get loaded and they see the statistics.

Same goes for opening socket types of various protocols.

Things really can break if we stop doing this.