random paladins failing: security_StatefulPermissions: Unexpected files/perms in stateful |
|||||||||||||||||
Issue descriptionFiled by sheriff-o-matic@appspot.gserviceaccount.com on behalf of tfiga@chromium.org winky-paladin:5905 failed security_StatefulPermissions: retry_count: 2, FAIL: Unexpected files/perms in stateful Builders failed on: - winky-paladin: https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8937440235204444688 test warning log: 08/22 20:56:59.545 ERROR|security_StatefulP:0221| 130089 4 drwx------ 2 authpolicyd authpolicyd 4096 Aug 22 20:46 /mnt/stateful_partition/home/.shadow/1be2995f8117a3e071c642d007c4a86217f5443a/mount/Alm6wAHN6A5pRfU4b7ouQD/EtAdOshNGsavLD+wlfZmND 08/22 20:56:59.575 WARNI|security_StatefulP:0261| Skipping missing user: 'getpwnam(): name not found: android-root' 08/22 20:56:59.857 WARNI|security_StatefulP:0261| Skipping missing user: 'getpwnam(): name not found: xorg' 08/22 20:57:00.311 WARNI|security_StatefulP:0261| Skipping missing user: 'getpwnam(): name not found: tpm_manager' 08/22 20:57:00.454 WARNI| test:0606| The test failed with the following exception Traceback (most recent call last): File "/usr/local/autotest/common_lib/test.py", line 600, in _exec _call_test_function(self.execute, *p_args, **p_dargs) File "/usr/local/autotest/common_lib/test.py", line 800, in _call_test_function return func(*args, **dargs) File "/usr/local/autotest/common_lib/test.py", line 464, in execute postprocess_profiled_run, args, dargs) File "/usr/local/autotest/common_lib/test.py", line 371, in _call_run_once self.run_once(*args, **dargs) File "/usr/local/autotest/tests/security_StatefulPermissions/security_StatefulPermissions.py", line 287, in run_once raise error.TestFail("Unexpected files/perms in stateful") TestFail: Unexpected files/perms in stateful
,
Aug 23
Happened on link-paladin too: https://luci-milo.appspot.com/buildbot/chromeos/link-paladin/32599
,
Aug 27
Set the winky-paladin to experimental so it is no longer blocking CQ CL's from landing; this has been broken for way too long.
,
Aug 27
,
Aug 27
,
Aug 27
ljusten@ do you know what file might be getting saved? Looks like it's owned by authpolicyd
,
Aug 27
,
Aug 28
This may have snuck into ToT. I see it on banjo-release. https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8937016556115429776
,
Aug 28
,
Aug 28
This is blocking green CQ runs and needs to be addressed immediately.
,
Aug 28
Removed winky-paladin from experimental because the problem is widespread.
,
Aug 28
Moved owner to current ARC Constable.
,
Aug 28
,
Aug 28
,
Aug 28
winky and banjo are 4.4.149 kernel. Not sure if that matters.
,
Aug 28
The enterprise folks added those symlinks I think, they are probably ok to whitelist.
,
Aug 28
This doesn't appear to actually have anything to do with ARC++ and Android files. The test is checking that all the files in the stateful partition have one of several expected owners. The test is however finding that there are files with an owner of 'authpolicyd', which is not in the list of expected owners, and that is why it is failing. I think the fix is to adjust the test to expect 'authpolicyd', by adding an entry for it in '_masks_byuser'. Since this is P0 and ljusten@ is both not local and apparently on vacation, I'll go ahead and make the fix.
,
Aug 28
This is failing the CQ, or other builders? Isn't the right solution here to just mark Verify-1 the CLs that are adding those paths?
,
Aug 28
And then let the enterprise folks land a test fix with their CL?
,
Aug 28
I think the change is already in the tree as it is showing in release builders sporadically. I'm trying to figure out where it was added. The failures seem to be inconsistent.
,
Aug 28
Ah I see. In that case I'll happily +2 a CL like the one described in c#17.
,
Aug 28
FYI this will pass on a freshly provisioned DUT. I'm trying to find the test that causes the file in question to be written.
,
Aug 28
,
Aug 28
I have concluded that this only fails when login_LoginSuccess is run before security_StatefulPermissions then it will continue to fail until a DUT is provisioned again.
,
Aug 28
Sample path /mnt/stateful_partition/home/.shadow/2de806527f624188fe4c1f28eea3099549f883d5/mount/Xo2Ztgc,9v1wsGqVFV3KsC/+XPt+sQ0E2WaryWFvFshLD
,
Aug 28
Uploaded crrev.com/c/1194432 which should fix this, though I was unable to reproduce the failure locally.
,
Aug 28
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/0a8f6bbd5f4406865607a27ffd73ba232608730b commit 0a8f6bbd5f4406865607a27ffd73ba232608730b Author: Lloyd Pique <lpique@chromium.org> Date: Tue Aug 28 23:48:26 2018 Whitelist authpolicyd for security_StatefulPermissions The security_StatefulPermissions test fails if it encounters a file in the stateful partition with an owner that is not in an internal expected owner whitelist. We encountered random failures where it was encountering files owned by "authpolicyd". This patch simply adds "authpolicyd" to the expected owner list. TEST=test_that login_LoginSuccess security_StatefulPermissions BUG= chromium:876988 Change-Id: I24e5c977c44b66f7675807c733494b3b02c0cf81 Reviewed-on: https://chromium-review.googlesource.com/1194432 Tested-by: Sean Kau <skau@chromium.org> Reviewed-by: Sean Kau <skau@chromium.org> [modify] https://crrev.com/0a8f6bbd5f4406865607a27ffd73ba232608730b/client/site_tests/security_StatefulPermissions/security_StatefulPermissions.py
,
Aug 29
While the whitelist is fine, we should also file a bug so that LoginSuccess cleans up after itself.
,
Aug 29
Do you mean that LoginSuccess should wipe stateful when it's done? I'm not sure what else it could do. Lowering priority as this is no longer an emergency.
,
Aug 29
Thanks for fixing it!
,
Aug 29
Reassigning to skau@, since this really isn't an ARC++ bug, and I'm not on top of the paladin etc trees to know for sure that it has been fixed and this bug can be closed.
,
Aug 29
tree is healed. Filed bug for follow up to fix login_LoginSuccess.
,
Aug 29
Bug for followup crbug.com/878907
,
Oct 25
Hi Sean, Could you please provide steps if this can be verified manually. Thanks.!
,
Oct 29
,
Nov 1
It's passing in the waterfall. That's all we're really looking for. |
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by tfiga@chromium.org
, Aug 23Components: Platform>Apps>ARC
Labels: OS-Chrome
Owner: yusukes@chromium.org