tests: fix security-udev-input-subsystem test #11390
Conversation
Permission denied could also be returned instead of 'Operation not permitted'.
Codecov Report
@@ Coverage Diff @@
## master #11390 +/- ##
=======================================
Coverage 78.37% 78.37%
=======================================
Files 931 931
Lines 106681 106702 +21
=======================================
+ Hits 83611 83633 +22
+ Misses 17867 17866 -1
Partials 5203 5203
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
I'm afraid that this change is not what we want, because when the error is "Permission denied" it means that our cgroup configuration was not setup/enforced, and this is exactly what this test is for.
What we could do, is disabling this test altogether and create an issue for it.
|
@mardy hi, thanks for taking a look, this is an old one, at some point @anonymouse64 confirmed that both messages could be expected, I don't remember the reason, I would add a comment in the test explaining the reason once Ian confirms that. |
| # device cgroup is in effect (because of rtc) and the device isn't in the | ||
| # cgroup. DAC is evaluated before AppArmor so since the device wasn't added | ||
| # to the cgroup, we see a DAC denial. |
There was a problem hiding this comment.
the issue with this test is that the underlying assumption here was true for a long time in the kernel, but only on accident. As per talking with the security team (specifically jj), the order in which the kernel evaluates LSM's is not defined and it just so happened to be that the device cgroup would be evaluated first for along time with ubuntu kernels, but that has recently changed so it is no longer deterministic.
That being said, I think we need to change these tests at some point to instead manually craft apparmor and device cgroup policy such that the expected one fails and we get the right message. I think this specific change in this PR is okay as long as we file a JIRA issue or launchpad bug etc to have someone look into manually modifying the policies in these tests (note it's not just this one that fails like this, there are others which have this same assumption built into them)
There was a problem hiding this comment.
@anonymouse64 thanks for extra insight into this!
| # device cgroup is in effect (because of rtc) and the device isn't in the | ||
| # cgroup. DAC is evaluated before AppArmor so since the device wasn't added | ||
| # to the cgroup, we see a DAC denial. |
There was a problem hiding this comment.
@anonymouse64 thanks for extra insight into this!
Permission denied could also be returned instead of 'Operation not permitted'.