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

[Cameron Simpson]

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!