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)
