Various sbox_integration_tests fail on Windows out of the box |
|||
Issue description
When I build and run sbox_integration_tests in a regular release build, these tests fail:
[158/158] FilePolicyTest.AllowReadOnly (156 ms)
8 tests failed:
FilePolicyTest.AllowReadOnly (../../sandbox/win/src/file_policy_test.cc:315)
FilePolicyTest.AllowWildcard (../../sandbox/win/src/file_policy_test.cc:376)
FilePolicyTest.TestReparsePoint (../../sandbox/win/src/file_policy_test.cc:581)
ProcessMitigationsTest.CheckWin10ImageLoadNoLowLabelFailure (../../sandbox/win/src/process_mitigations_imageload_unittest.cc:369)
ProcessMitigationsTest.CheckWin10ImageLoadNoLowLabelSuccess (../../sandbox/win/src/process_mitigations_imageload_unittest.cc:360)
ProcessMitigationsTest.CheckWin10ImageLoadPreferSys32_Baseline (../../sandbox/win/src/process_mitigations_imageload_unittest.cc:420)
ProcessMitigationsTest.CheckWin10ImageLoadPreferSys32_Failure (../../sandbox/win/src/process_mitigations_imageload_unittest.cc:461)
ProcessMitigationsTest.CheckWin10ImageLoadPreferSys32_Success (../../sandbox/win/src/process_mitigations_imageload_unittest.cc:441)
The ProcessMitigationsTest test cases have comments that say "Must run this test as admin/elevated." They seem to be failing because they can't copy things into system32, which seems self-explanatory. Is that intentional? The comment is attributed to Penny from back in 2017, probably when these tests were new. Should the tests check for this case and intentionally pass or error out if they aren't run with admin privileges?
Why do these tests pass on the bots? Maybe they only pass because the tests exit early for older versions of Windows:
// Must run this test as admin/elevated.
TEST(ProcessMitigationsTest, CheckWin10ImageLoadPreferSys32_Baseline) {
if (base::win::GetVersion() < base::win::VERSION_WIN10_RS1)
return;
As for the FilePolicyTest suite failures, I have no idea what's up. That seems to be a local issue that doesn't reproduce on the bots. I'll share more info on them when I get it. Here are the logs: https://pastebin.com/3tKGXUXy
,
Jun 19 2018
Yes, if running locally, some of the tests need to be run from an elevated cmdline. Certainly not all of the tests you mention here though. The bots are configured to run certain test suites elevated. I haven't had a chance to try to replicate yet Reid - but I don't have any issues on my latest win10 machine. If you don't figure it out, and you don't hear from me by the end of next week, feel free to ping me as a reminder! :)
,
Jun 19 2018
The bots run these elevated, and that's by design. I think this is a WontFix https://cs.chromium.org/chromium/src/testing/buildbot/chromium.win.json?l=1742
,
Jun 19 2018
OK, let's do that. I think I was looking for "elevated" or "admin", not "integrity". It's hard to work out from the test logs that sbox_integration_tests is running in an elevated admin context: https://logs.chromium.org/v/?s=chromium%2Fbuildbucket%2Fcr-buildbucket.appspot.com%2F8943255285042220432%2F%2B%2Fsteps%2Fsbox_integration_tests_on_Windows-10-15063%2F0%2Fstdout I don't see any mentions of integrity or elevation in the stdio, other than test names.
,
Jun 19 2018
if you click on that link then follow the link to the swarming job (it's at the top, wrapped in ascii art, beginning with "Shard 0") - then that's https://chromium-swarm.appspot.com/user/task/3e32d37825714b10 - and that lists the job as 'integrity: high' I admit it's non obvious that the test is running elevated from the swarming output, but it's apparent from the swarming params... maybe we could do better in the output? |
|||
►
Sign in to add a comment |
|||
Comment 1 by r...@chromium.org
, Jun 14 2018