Fix GetConnectionCredentials usage on non-AppArmor systems
If AppArmor is not available on the system, then the response from GetConnectionCredentials
isn't guaranteed
to make sense to the AA-centric code. Link against AA, ask if it's in use, treat as unconfined if not.
For this purpose, we need control over whether AA is "in use" during the tests, otherwise we depend on
test environment details. For this purpose, add a LDM_MOCK_AA_POSITIVE
envvar switch to control the behaviour.
(When AA-like D-Bus responses are expected in the tests, then they already resort to mocking those calls.)
CC @sunweaver @peat-psuwit: Here's the fix for LDM, happy about feedback.
A leftover issue after this would be why the test is failing at !24 (comment 1746801673) in the first place, but I find it hard to debug this past the D-Bus call border.
The calling side starts in TestGroupManagerWatch::testErrCallbackIsExecuted(). The called side, AFAICT, would more or less start at DownloadManager::createDownloadGroup, reach AppArmor::*
, D-Bus call GetConnectionCredentials
, get kernel
as a response, ???. End effect is that QVERIFY(!_calledSuccess);
fails, so I guess something signals "a-OK" there when it shouldn't?