Cameron Simpson wrote:
On 06Oct2011 04:26, Glyph <gl...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
