<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 7, 2011, at 7:10 AM, Cameron Simpson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Menlo; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">The point here is security, not test coverage: if a procedure is known<br>to be broken as a regular user, is it not highly unsafe to then run it<br>as root?<br></span></span></blockquote></div><br><div>No. As I mentioned previously, any environment where the tests are run should be isolated from any resources that are even safety-relevant, let alone safety-critical, whether they're running as a regular user _or_ root.</div><div><br></div><div>In theory, one might automatically restore the run-as-root buildslave VM from a snapshot before every single test run. In practice this is probably too elaborate to bother with and an admin can just hit the 'restore' button in the fairly unlikely case that something does happen to break the buildslave.</div><div><br></div></body></html>