[Python-Dev] cpython (3.2): Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as

[Steven D'Aprano]

Cameron Simpson wrote:
> On 06Oct2011 04:26, Glyph <glyph at twistedmatrix.com> wrote:
> | On Oct 5, 2011, at 10:46 PM, Cameron Simpson wrote:
> | > Surely VERY FEW tests need to be run as root, and they need careful
> | > consideration. The whole thing (build, full test suite) should
> | > not run as root.
> | 
> | This is news to me - is most of Python not supported to run as root?
> | I was under the impression that Python was supposed to run correctly as
> | root, and therefore there should be some buildbots dedicated to running
> | it that way.  If only a few small parts of the API are supposed to work
> | perhaps this should be advertised more clearly in the documentation?
> 
> Pretending the snark to be slightly serious: you've missed the point.
> The builtbots are building unreliable code, that being the point of the
> test suite. Doing unpredictable stuff as root is bad juju.


Sorry Cameron, it seems to me that you have missed the point, not Glyph. 
If the builtbots were predictable, there would be no point in running 
them because we would already know the answer. But since they *might* 
fail, they need to be run: that is an argument in favour of tests run 
explicitly as root, not against it.

Since Python running as root is supported[1], then it must be tested 
running as root. What's the alternative? Wait for some user to report 
that Python nuked their production system when run as root? Better that 
we find out first hand. It would be embarrassing enough if (say) 
list.append crashed our test system. How much worse would if be if the 
first time we found out about it was after it did so to Google's 
production servers?

To put it another way:

Doing unpredictable stuff as root on a production machine is bad juju. 
Doing unpredictable stuff as root in order to find out what it will do 
*before* putting it into production is absolutely vital.


> Running the builtbots and their tests should not be run as root except
> for a very few special tests, and those few need careful consideration
> and sandboxing.

Are you suggested that they aren't currently sandboxed?


> | Ahem.  Sorry for the snark, I couldn't resist.  As terry more reasonably put it:
> | 
> | >> running buildbot tests as root does not reflect the experience of
> | >> non-root users. It seems some tests need to be run both ways just for
> | >> correctness testing.
> | 
> | (except I'd say "all", not "some")
> 
> No. Terry is right and you are ... not. Most tests need no special
> privileges - they're testing language/library semantics that do not
> depend on the system facilities much, and when they do they should work
> for unprivileged users.
> 
> Of course they _should_ work as root (barring the few tests like the
> issue cited, where things are expected to fail but don't because root is
> unconstrained by the permission system).
> 
> HOWEVER, the whole suite should not be _tested_ as root because the code
> being testing is by definition untrusted.

So what you are saying is that the most critical situation, with the 
greatest consequences if there is a failure, should *not* be tested, but 
taken on trust that it will just work as expected.

This makes no sense to me. I would say that testing as root is more 
important, not less, because the consequences of unexpected failure is 
so much worse.

It seems to me that you are putting the security of the build-bot ahead 
of people's real-life production systems, that you expect them to run 
*untested code* in production as root. To me, this seems wrong.

What exactly is your fear? That Python run as root will be able to 
escape the jail it is running in and do bad things to the host machine? 
That's a legitimate concern, but that's an argument to be taken up with 
the sys admins who set up the jail. It's not an argument against testing 
as root. It's an argument against testing as root *badly*.





[1] If not, that will come as a mighty big surprise to Red Hat, among 
others, who use Python for system tools run as root.

-- 
Steven