This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Running GCC as root


Daniel Jacobowitz <drow@false.org> writes:

> On Mon, Feb 14, 2005 at 11:03:25AM -0800, Zack Weinberg wrote:
>> Where I'm coming from is, this (running gcc as root) *was* just bad
>> practice, and/or a matter of site policy, up till someone found a
>> scenario where a legitimate invocation caused breakage when run as
>> root -- and not breakage that we have any way of fixing, since it
>> boils down to a bug in a vendor assembler.  At that point it becomes
>> something that should be disallowed, IMO.
>
> Then refuse to invoke the assembler pointing at /dev/null on that
> platform if you want to work around the bug.

I think that would wind up being way more effort than we want to go to
to cater to a bug in someone else's code.

A lot of the motivation for the really big hammer is that it's easy
and guaranteed to catch all the problem cases, at the admitted cost
of a lot of collateral damage.  I'm not very attached to it myself,
and since the reaction is universally negative, let's consider it
withdrawn (comments below notwithstanding).

That leaves us with the other patch, which should in fact fix the
original poster's problem.  It does definitely break "make install"
without a previous "make", but as I said to Ian, I doubt that works
anyway.  And it should be possible to make that go away in 4.1 when
libgcc moves to its own directory (hope hope) and we can do a proper
configure run for it.

> I was not making up examples.  You will bust Debian package builds
> back to the stone age.  For instance, many software distributions
> will run configure during 'make clean', and Debian packages run
> 'make clean' as root (or fakeroot).

... both things I have always considered to be bugs, by the way.  (I
know why both of them happen, and I know it's hard to change either.)

>> The check was placed in toplev.c instead of gcc.c precisely because
>> there are genuine needs to run the preprocessor (i.e. gcc -E) as root.
>
> Huh?  You admit legitimate uses of PART of gcc as root, and are
> no legitimate uses of the REST of it?

Well ... yes, actually.  The preprocessor is often used as a general
text processor for e.g. configuration files, which *does* often need
doing as root.  I'm not happy about this either from a least-privilege
standpoint or from an appropriate-tool-for-the-job standpoint
(q.v. lengthy rant in CPP manual about its not being designed as a
general text processor) but it's certainly a lot more ingrained than
running the full compiler as root, which I had (it seems naively)
hoped everyone would agree was always wrong, although perhaps hard to
avoid in some cases.

If we are in fact trying to cater to people who run the full compiler
as root, then I suppose there's some auditing to be done to make sure
GCC itself doesn't unlink /dev/null ever, or similar things...

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]