Jump to: navigation, search

This page is a guide for (open)QA people or other testers on common pitfalls that we see when it comes to testing for SELinux bugs.

Thank you for doing the testing, it is really appreciated!

What we need to quickly process issues from (open)QA

If you have a openQA test run with the issue:

  • Always (!) add "SELinux" in the summary so that we can find the issue, otherwise it will be gone forever
  • Always link the openQA test run
  • Please also paste the AVCs in the comment, since the openQA runs will be purged after a while. This helps us in the future to see if issues have happened before.

If there is no openQA test run:

Common problems

Problem 1: The issue seems to still occur even though the assignee says it is fixed? Is it not fixed? What should I do now?

Sometimes you will see that the issue does not seem to be fixed in subsequent openQA runs even though the bug assignee tells you it is fixed. This could have different reasons. To avoid duplicate efforts, please firstly check if the issue is really not fixed or if it is a special case in openQA by checking this list:

There will be one or multiple submitrequests (SRs) linked in the bug by the person fixing the SELinux bug. Please open the links and check:

  1. Are the SRs accepted? If they are declined, is there a superseeding request that is accepted? If the SR is declined and there is no superseeding request, it is quite probable that you are testing with the wrong selinux policy version. If you see that we did not notice the declined SR, please notify us in the bug and we will create a followup SR.
  2. Are you testing the correct project? For example: The linked SR in the bug could be to Base:System/mypackage, but you are testing openSUSE:Factory/mypackage. Please then check if the content of the SR to Base:System/mypackage is already present in openSUSE:Factory/mypackage (usually by checking the changelog or incoming SRs). If the fix is not in the project that you are testing, then you are testing the wrong package version. Please notify the bugowner of openSUSE:Factory/mypackage to create a submission from the devel project. This can be done by reassigning the bug to the bugowner and adding a comment in the bug.
  3. Are you testing the correct policy version? The linked SR will usually have a selinux-policy version that you can see in the .spec file in the `Version:` tag. Please check if the version is the same version that is used in the test. Usually you can see the version used in the test in the openQA log or by via `zypper info selinux-policy` on the machine. If it is not the same version, then please investigate why. Some causes could be:
  • The image that is used for testing was not built with the fixed version. Indications could be that in the openQA log the AVC pops up directly on first boot before the update phase and then disappears after the update phase when queried with `ausearch -m avc -ts boot`. In this case, please contact the person building the images and ask them to rebuild (these are usually the release managers, not the selinux people).
  • Something else in the test failed, e.g. the wrong update repositories, broken updates due to OBS issues,... In this case, please try to fix the cause of the failure
  • see causes listed in 1. and 2.

If after checking this list everything seems fine on the (open)QA side and the issue is really not fixed from the bug assignee, please feel free to report this back to us.