linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>, X86 ML <x86@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: Does vdso_install attempt to re-compile objects under root privilege?
Date: Tue, 23 Apr 2019 16:38:35 -0700	[thread overview]
Message-ID: <CAHk-=wiV2gLQkp6JFQYewL1uzgWnwEK9fKWP3AfZbcu2Lv_GrQ@mail.gmail.com> (raw)
In-Reply-To: <CALCETrVSM0vrMVr2y0ECAQ=tNGvBs=im2Kxongq-jvdzUBevbg@mail.gmail.com>

On Tue, Apr 23, 2019 at 11:47 AM Andy Lutomirski <luto@kernel.org> 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

  reply	other threads:[~2019-04-23 23:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03  5:17 Does vdso_install attempt to re-compile objects under root privilege? Masahiro Yamada
2019-04-23 18:47 ` Andy Lutomirski
2019-04-23 23:38   ` Linus Torvalds [this message]
2019-04-23 23:57     ` Andy Lutomirski
2019-04-24  4:06       ` Linus Torvalds
2019-04-24  3:40     ` Masahiro Yamada
2019-04-24  6:57     ` Peter Zijlstra

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='CAHk-=wiV2gLQkp6JFQYewL1uzgWnwEK9fKWP3AfZbcu2Lv_GrQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=x86@kernel.org \
    --cc=yamada.masahiro@socionext.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).