Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4180588yba; Tue, 23 Apr 2019 16:59:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqxBtZTrxr6BLgsp7cX3/7dbMhJryZBwEb/wsXaGUVkGIV69rpli6j6Q/jPVG9MNmO2/jB25 X-Received: by 2002:a17:902:7885:: with SMTP id q5mr29224822pll.12.1556063946003; Tue, 23 Apr 2019 16:59:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556063945; cv=none; d=google.com; s=arc-20160816; b=QACuWV++QushLNAbu8b0NQTSyZSOlcPX1153HWUTKskfKX/565NsLF73na0xaZkTFK WVL3oeCu/BuWa+f9Ifkr1F78VgoH+NZET0sxOj5bnKOMRYkITYZKoMaZk/cpijpehyJb ZuJcoZVeajAzvZke7RL45uto7z2n/SJz8mz98nBlbVa6FK0DOAb27eqYQHMAK6avAobd Hogzo1z9SLBzHId/HCk2Z4IcXUGtc7qXG/iRIi3jEQV2Ac6yV3dttPdqGN5pejUcTYeS F6/BlNprNduEX7CRZYPxYSSKzzFCL9xTe11L78gLdaEd0O3Ll6GGTPHeEvJiFvX4/2AK Ji5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=VkhkJzaUTJucDFJB4blA7Ip3YzN/Wig4l799HSQpMjA=; b=sa8ULK6Anz1zF92tyFSiMIfqVefzTi7Wkw9/ZqQUAq3VfLG4EgdGwOMBb1X7B+Lt94 q1h0PxMvVEvDrwlsHAmeJ7xiojALgwDfHRvolsdSDLTIELFRWq+SZ7BIvPOBCtgd2H0v Z4BvcGkoWyRUs2h1JIjJ1E3t4uKmSJr79tBxvgPGYUEou4dzm85L1LYaXGkgfAHbX52U P3y2KZ6EqJaggUPOjjQa62oNSyqCgW9lLzQZ1femKIczmkcPDMpfMpK/k0jew+oyY7GD eiIHx749EOxRqlDAQo3MtDsgVLWWZh9SORpmVvbz3lc/HW0NFQOsixyki+gDNRLWw1Jq 6cLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=nC43+fai; 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 z8si16428932pgc.79.2019.04.23.16.58.49; Tue, 23 Apr 2019 16:59:05 -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=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=nC43+fai; 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 S1728729AbfDWX5k (ORCPT + 99 others); Tue, 23 Apr 2019 19:57:40 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:46348 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727831AbfDWX5j (ORCPT ); Tue, 23 Apr 2019 19:57:39 -0400 Received: by mail-pg1-f194.google.com with SMTP id v2so5978423pge.13 for ; Tue, 23 Apr 2019 16:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VkhkJzaUTJucDFJB4blA7Ip3YzN/Wig4l799HSQpMjA=; b=nC43+faiEiLWdsHjzm1N6VK4KXtojrzbDDbnRGt4eroC4+Y5cvIarBcNfDIr4qeqM1 AIlieglWT/Zp5ZK5z0HaN75BYOOPvIkfHMlx1csp6qQzNjoKx+oKXDExBgnGF0F0bH7o 18PjxFTfyN/hkCYP90S5zq8yc1RFP1xEHsayb6Ee4sbV4NODRQmPUmlbBz6uFYRU5ncE XrtPqAdlfxYqsgWO11f19hveuEWVEPl72WDLk+GzF5CZaCTqZh8MnCdmdw+rU6SR6lr2 TR2C71Dsoln2DRoHNNxBCj1HhDzDQHOdR/WQaGPkRbHYQa2Sh9fsIS2w6LppNKOdGDpG BSpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VkhkJzaUTJucDFJB4blA7Ip3YzN/Wig4l799HSQpMjA=; b=la0rzQEF0vZg8QwACqCXjLVLDPDFLPeTu+jFMUFXVpA9DINdcPRLpe9yhrB2aHLVfw cD9twLaAMUWaMUFjbas7ejgqU43si9vxnQ6vyXbbCFKdAX5swIaKQo7fGQRRIG1mZY6O QARFgAv35J3wA/fpqiUxKMf9PxXUnDM63z3PNlW0Dlo6YfugsYh+HepnuxnbamcdaFy+ ePsWDIE70Mp7YrNQ/l2g1+IZWJq+1wy9H0ukgGyx285hKJ6rPkzeTwp1CB/VgqA/p4gj eKAAFumP3PFGk5vwR3skb5JNaLFuXCHTstSBn/uIBgxsNtX9yMJLeNMSXZBGMxD/XktJ j1RQ== X-Gm-Message-State: APjAAAUIn53YsDJWUZ8otfxRY0tRVCFRte8cyoWf1ruXgwmfeyb3X+7x G+jDoSShHATI11MwCTSYOGg32w== X-Received: by 2002:a63:1e4f:: with SMTP id p15mr17410496pgm.289.1556063858579; Tue, 23 Apr 2019 16:57:38 -0700 (PDT) Received: from ?IPv6:2600:1010:b02a:3fc2:653f:d30:32fb:18de? ([2600:1010:b02a:3fc2:653f:d30:32fb:18de]) by smtp.gmail.com with ESMTPSA id m11sm36068085pgd.12.2019.04.23.16.57.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Apr 2019 16:57:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Does vdso_install attempt to re-compile objects under root privilege? From: Andy Lutomirski X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Tue, 23 Apr 2019 16:57:36 -0700 Cc: Andy Lutomirski , Masahiro Yamada , Linux Kernel Mailing List , linux-arch , X86 ML , linux-arm-kernel Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Linus Torvalds Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Apr 23, 2019, at 4:38 PM, Linus Torvalds wrote: >=20 >> On Tue, Apr 23, 2019 at 11:47 AM Andy Lutomirski wrote:= >>=20 >> Hmm. I suppose an alternative would be for vdso_install to fail if >> the vdso isn't built? >=20 > 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". >=20 > So anybody who builds the kernel as root is doing something seriously > wrong, in my opinion. >=20 > That's partly exactly _because_ we have a lot of magical and very > powerful build rules, and complicated implicit things going on. >=20 > 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". >=20 > 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. >=20 > 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. >=20 > 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. >=20 > So all of that simply boils down to "root should not be running those > complex rules for our config and dependency magic". >=20 > At the same time, "make install" obviously needs to be done as root. >=20 > 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". >=20 > So yes, I'd much prefer just failing over trying to build as root (or > even trying to figure out dependencies as root). >=20 >> What's the ideal outcome here? >=20 > 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. >=20 > 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'". >=20 > So I think the ideal outcome is just "fail if you can't find the files > to install". >=20 >=20 To clarify, this is =E2=80=9Cfail if you can=E2=80=99t find the files to ins= tall, but don=E2=80=99t even try to check whether those files are up to date= =E2=80=9D, right?=