security_StatefulPermissions fails due to files in /var/lib/ml_service |
|||||
Issue descriptionIn the tricky-tot-chrome-pfq-informational run at http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8928504289375401248, security_StatefulPermissions failed with "Unexpected files/perms in stateful". 11/29 12:47:23.815 ERROR|security_StatefulP:0223| 407 4 drwxr-xr-x 3 ml-service ml-service 4096 Nov 29 11:48 /mnt/stateful_partition/encrypted/var/lib/ml_service 409 4 drwxr-xr-x 2 ml-service ml-service 4096 Nov 29 11:48 /mnt/stateful_partition/encrypted/var/lib/ml_service/metrics 413 4 -rw-r--r-- 1 ml-service ml-service 12 Nov 29 11:48 /mnt/stateful_partition/encrypted/var/lib/ml_service/metrics/cycle.start 414 4 -rw-r--r-- 1 ml-service ml-service 12 Nov 29 11:48 /mnt/stateful_partition/encrypted/var/lib/ml_service/metrics/version.hash Probably security_StatefulPermissions.py needs to be updated to know about the ml-service user. I suspect that this fails inconsistently depending on whether any other tests that ran earlier induced ml-service to create these files.
,
Dec 2
,
Dec 3
,
Dec 3
It happens when the e.g. ML Service Tast test runs before this permissions test. E.g. on amd64-generic VM: $ tast -verbose run localhost:9222 platform.MLServiceBootstrap $ test_that --board=amd64-generic localhost:9222 security_StatefulPermissions Will add ml_service to the expected dirs for the permissions test.
,
Dec 3
Actually running the Tast tests in advance I get more errors related to drivefs probably because the Tast test logs in. Maybe if certain ML Service unit tests are run before security_StatefulPermissions this can show up. Either way I will add to the expected dirs.
,
Dec 4
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/dd5bc73a25efa6a40b076e8bf36dffe7f3ea4a6a commit dd5bc73a25efa6a40b076e8bf36dffe7f3ea4a6a Author: Andrew Moylan <amoylan@chromium.org> Date: Tue Dec 04 00:41:06 2018 security_StatefulPermissions: Add /var/lib/ml_service ML Service might run (e.g. in a test) before security_StatefulPermissions, and creates files under /var/lib/ml_service. This CL makes security_StatefulPermissions aware of this dir. BUG= chromium:910387 TEST=test_that ... security_StatefulPermissions after "start ml-service" in VM Change-Id: I50f9af7e04c93e5070b59a2dbc107670339aa56b Reviewed-on: https://chromium-review.googlesource.com/1356662 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Andrew Moylan <amoylan@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/dd5bc73a25efa6a40b076e8bf36dffe7f3ea4a6a/client/site_tests/security_StatefulPermissions/security_StatefulPermissions.py
,
Dec 4
This failure is now in PFQ. Escalated to P0 per the gardener guideline. https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8928072362862786896 Hi amoylan@, is this fixed? Is it because the PFQ hasn't picked up your fix?
,
Dec 4
I don't think the failure you linked to is the same problem. See https://storage.cloud.google.com/chromeos-autotest-results/263475185-chromeos-test/chromeos4-row2-rack3-host2/security_StatefulPermissions/debug/security_StatefulPermissions.ERROR; all the files that the test complained about appear to be under /mnt/stateful_partition/home/.shadow. I'm planning to delete security_StatefulPermissions soon (after replacing it with the security.StatefulFiles Tast test), so if you can't find a bug already tracking the .shadow failures and file a new one, feel free to assign it to me. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by derat@chromium.org
, Dec 1