coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests: misc/sort-exit-early: do not run as root.


From: Nick Alcock
Subject: Re: [PATCH] tests: misc/sort-exit-early: do not run as root.
Date: Thu, 30 Aug 2012 13:47:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

On 30 Aug 2012, Jim Meyering uttered the following:

> A word of caution:
>
> There have been exploitable flaws (albeit rare) in these tests over
> the years, and if you had regularly run all of them as root on a shared
> system, it might have been easy to exploit.  The root-only tests are
> more carefully audited, precisely because we regularly run them as root.

Yeah. The systems on which I run these tests as root are shared only
with the trusted. (My autobuilder automatically does a very-expensive
'make check' as non-root, a 'make check-root' as root, then a 'make
check' as root, every time I upgrade coreutils. I don't upgrade to every
release, but most.)

>     If you want to use some other non-root username, specify it via
>     the NON_ROOT_USERNAME environment variable.

I use the username that did the compilation, which is already trusted to
raise privileges to root to do the installation -- though not to run
'make install' as root, that is fakerooted. The compilation and testing
are also done in a freshly-created loopback-mounted filesystem that is
erased right after a successful build, so only a bug that led to things
being changed outside the test filesystem could lead to problems that
persisted past the build. I am not aware of any such ever having
happened.

I figure that I can trust the coreutils maintainers not to intentionally
insert ruinous code into the makefile or testsuite, thus I feel it is
*relatively* safe to run 'make check' as root, where it would not be for
a random package. After all, I run coreutils binaries as root all the
time.

(This is also by no means the most dangerous testsuite that gets run as
root on this machine, though the others are part of my job and I wrote
the testsuite driver so should they go wrong I'll have only myself to
blame as I put the smoking fragments of the machine back together!)

>     I find that it is best to unpack and build as a non-privileged
>     user,

Anyone who compiles as a privileged user deserves everything they get,
IMHO. I used to do it when building Perl packages with CPAN.pm, and
bizarre problems and file creations, particularly in the root directory,
were not rare. (I had a momentary frisson of fear upon upgrading
coreutils last, because hey! / has suddenly changed! But it hadn't, it
was just the relative-symlink-in-/ bug and Mike Frysinger had already
reported it.)

>                We get much less test coverage in that mode

There have been remarkably few problems. I think this is the first I've
seen in years that goes wrong only when testing as root.

-- 
NULL && (void)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]