Skip to content

Fix GetConnectionCredentials usage on non-AppArmor systems

Cosima Neidahl requested to merge OPNA2608/lomiri-download-manager:fix/AA-GetConnectionCredentials-usage into main

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 an AA-mocking library that let's us control this response.

(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. Very unsure about the way I had to mock the AA call, not sure if that's the best approach.

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?

Merge request reports