Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp111517yba; Tue, 23 Apr 2019 20:44:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqx8MTc0h6uSs3cQnVDb/NZyD6yuNeJVT1dg90g5bes9VTPAtDBbMqRCdm5ZIb8hyCXupc3Q X-Received: by 2002:a62:12d0:: with SMTP id 77mr31161647pfs.15.1556077459833; Tue, 23 Apr 2019 20:44:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556077459; cv=none; d=google.com; s=arc-20160816; b=PRPadaAWgvF3r3VpaLaUkNF07M14e2cbD2mMUAmKYYl6uUs/UBMn6HGA6PApdfrHua 2vThTmmtn5G2pcyzeEoP4OOB9O/9kbzhl4FDPi32/W+SIGY7Jsff71zc3+1ECVZLTDRk 6OdXIrvQTPLlSnPj1m6oSn3u7GYDNtEP/r4AavFSMivDHiIfUmSpERLmklgfhG3sxeHV F9nDEtM8wn79PP4kax7e/CGb6kyl14JKA+bAy8wovX4LLdlOajr61te/AqleJ0ntQ3oh kmw4YxBqTg3TSMfVNNWZjkyY0kDi2QkCI4ju4nE3GISE7Sto6tgpvq6As6EfUOhXt5Z+ sCUA== 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:dkim-filter; bh=YN5R4J8MFslfEWj4/fJ8NFzh/Uc6ypge5CDtrk7AyuA=; b=DR6h5s0wPp1kz27aMDCrZpO+Az6/y1wT+kxjd+pLxu3P8LZpGx6CXJdIYtsWQwo2dH mln/KlEDGb4LtUIWD6/LAKCjbwSRmGTis7MP23qv5k7LlRQWYRqpNmKiY/iPMDdhlAHZ 7PA8reLinxsvYzpqjTLT1bKDolS/zU0J96GAMZ4g8ktjpugm7SY9L6Q8wOoX00wwyCmv kHQV8vVv3nhr1T3xxFp3GTfGuVQrYH72H7HY5zccWyKdoCIhbxkduq+wdorzk4l2fsEe uXKyUJ14AAva9GUuAjcDmP/67mkPZLh3bniSCug/ShTmklUygmG/ymdScKGRQWeoSNBZ eG5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=yXa9OeV5; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y16si4445799pga.34.2019.04.23.20.44.03; Tue, 23 Apr 2019 20:44:19 -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=@nifty.com header.s=dec2015msa header.b=yXa9OeV5; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728928AbfDXDlx (ORCPT + 99 others); Tue, 23 Apr 2019 23:41:53 -0400 Received: from conssluserg-03.nifty.com ([210.131.2.82]:39541 "EHLO conssluserg-03.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726802AbfDXDlx (ORCPT ); Tue, 23 Apr 2019 23:41:53 -0400 Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (authenticated) by conssluserg-03.nifty.com with ESMTP id x3O3fOQN020791; Wed, 24 Apr 2019 12:41:25 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-03.nifty.com x3O3fOQN020791 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1556077285; bh=YN5R4J8MFslfEWj4/fJ8NFzh/Uc6ypge5CDtrk7AyuA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=yXa9OeV5MiUdoVbJHssVEmuZCLL1f8KVovbIqfsrBQQvnQm6u+VArc3zD1GEsNLET Ux11nkMBUqvqDTJQjq4KslKC6DGysS9H8fkN0TrA4DzVrZ7w5qLWA6aNHpgAGqkl/0 6oZp6XEbNpa4uxHb7rdkLQtPTuH+WYWCnqmEZ9OQX4xnGBIh6hy2xBDSLOaacRNoKA 8/cSZ51RvyTwRY1ZmQsLr8iOR7maM2oNw/6wh5COjd0NR3qee3HSx7UgQIwaxKWY6j Pw6pGYumjrFz8Ar+k9t5qNQv3Ow9/uklBmGjB7fm2CNknpbK67i7A+QAEEhF8DhDyW CJMh7Zzz/Jicw== X-Nifty-SrcIP: [209.85.217.42] Received: by mail-vs1-f42.google.com with SMTP id n4so9579175vsm.3; Tue, 23 Apr 2019 20:41:25 -0700 (PDT) X-Gm-Message-State: APjAAAXHwmoE4p+SEnnO/rNdV6QzcVKnvL7Qy1dL9CZEWJT9735r0f3A HZ7QFvg/HVQKeTwq5pJgxbyCVWWBKIaRK7NBhEw= X-Received: by 2002:a67:7a43:: with SMTP id v64mr16393701vsc.54.1556077284286; Tue, 23 Apr 2019 20:41:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Masahiro Yamada Date: Wed, 24 Apr 2019 12:40:48 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Does vdso_install attempt to re-compile objects under root privilege? To: Linus Torvalds Cc: Andy Lutomirski , Linux Kernel Mailing List , linux-arch , X86 ML , linux-arm-kernel 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 On Wed, Apr 24, 2019 at 8:40 AM Linus Torvalds wrote: > > On Tue, Apr 23, 2019 at 11:47 AM Andy Lutomirski wrote: > > > > Hmm. I suppose an alternative would be for vdso_install to fail if > > the vdso isn't built? > > I absolutely abhor even the concept of building the kernel as root, > and I think it should be actively disallowed. Our build system is > good, but it's good as in "clever and complex" rather than necessarily > good as in "very secure". > > So anybody who builds the kernel as root is doing something seriously > wrong, in my opinion. > > That's partly exactly _because_ we have a lot of magical and very > powerful build rules, and complicated implicit things going on. > > For example, our dependencies aren't even about just the files in the > kernel repository itself, we have clever things like "if the compiler > has been updated and features or version changes, we'll automatically > rebuild, because it's part of our clever build system checks". > > But that is also part of the reason why I absolutely do *not* want any > root-building to happen, because our build setup is simply way too > clever. > > If root builds stuff, you'll end up with root-owned generated > subdirectories or various config files etc, and even if you don't have > security issues, it can complicate the build later as a regular user. > > I've had the build occasionally fail in odd ways, because some > root-owned file was now no longer removable (usually it's the > auto-generated header files in the directory, and the root-generated > and owned directory is now not writable by the developer any more). > And every time it happens, I shudder. > > So all of that simply boils down to "root should not be running those > complex rules for our config and dependency magic". > > At the same time, "make install" obviously needs to be done as root. > > All of which is why I opine that "make install" should never build > anything at all, it should purely be used as a "install previously > built files". > > So yes, I'd much prefer just failing over trying to build as root (or > even trying to figure out dependencies as root). > > > What's the ideal outcome here? > > I'd basically like the rule for "make install" to be that it never > ever generates a single file in the build tree, so that there are > never any root-owned (or root-overwritten) files there. > > So "make install" should even avoid all dependency checking, for the > simple reason that if you happen to do a system update between "make" > and "make install", our smart dependencies should never say "oh, the > compiler version has changed, so now I'll rebuild everything as root > just because 'make install'". > > So I think the ideal outcome is just "fail if you can't find the files > to install". > > Linus I assume this is ACK to change vdso Makefiles. I will send patches. Thanks. -- Best Regards Masahiro Yamada