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

Cameron Simpson cs at zip.com.au
Fri Oct 7 13:10:36 CEST 2011

On 07Oct2011 06:50, Glyph <glyph at twistedmatrix.com> wrote: | On Oct 7, 2011, at 6:40 AM, Cameron Simpson wrote: | > I think that the build and the tests should be different security | > scopes/zones/levels: different users or different VMs. Andrew's | > suggestion of a VM-for-tests sounds especially good. || To me, "build" and "test" are largely the same function, since a build | whose tests haven't been run is just a bag of bits :). But in the sense | that root should never be required to do a build, I don't see a reason | to bother supporting that configuration: it makes sense to always do | the build as a regular user.

I don't mean buid as root and test as regular user, I mean build as regular user and test as different user. This can be used to prevent the test user from having write permission to the built code.

My thinking is that the "build" is a well defined set of "safe" operations: copy the source (safe, just a data copy), compile the source (safe, presuming bug-free compiler). Of course I'm glossing over any autoconfiguration shell scripts and makefiles full of source-code-supplied shell commands - nasty nasty.

Basicly I was taking the view that a "build" should be a safe "source code to machine code" translation process.

By contrast, the tests run the somewhat-unknown test suite. Not an inherently "safe" procedure.

Think of the build being like a PDF viewer rendering a document to the display. And the tests as being the user reading a list of instructions off that display and doing stuff. It ought to be safe to render the PDF; the user's actions are "unsafe".

| > And that I think the as-root tests suite shouldn't run unless the | > not-root test suite passes. || Why's that? The as-root VM needs to be equally secure either way, | and it's a useful data point to see that the as-root tests didn't | break, if they didn't; this way a developer can tell at a glance that | the failure is either a test that needs to be marked as 'root only' | or a change that causes permissions to be required that it shouldn't have. || (In general I object to suggestions of the form "don't run the tests | unless X", unless X is a totally necessary pre-requisite like "the | compile finished".)

Suppose a test is dangerously broken through ineptitude or even malice. Extreme example: a test makes a bunch of test files and cleans up with "rm -r /". (Non-malicious scenario: "rm -r ${testdatatree}/", with $testdatatree accidentally undefined, eg through a typo.)

Such a test will fail when unprivileged. (Of course a mlicious test might say "do not set off the bomb unless I am root":-)

The point here is security, not test coverage: if a procedure is known to be broken as a regular user, is it not highly unsafe to then run it as root?

Cheers,

Cameron Simpson <cs at zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/

1st Law Economists: For every economist there exists an equal and opposite economist. 2nd Law Economists: They're both always wrong!

More information about the Python-Dev mailing list