#50122 lib389 - call system selinux commands instead of using python-selinux module
Closed: wontfix 2 years ago by mreynolds. Opened 3 years ago by mreynolds.

Issue Description

There are a few issues with using the python-selinux module:

So for now we should create wrappers for system() calls to the native selinux commands


We also can't guarantee it's available on opensuse either because opensuse uses apparmor or selinux. So I think we need to check if the python-selinux module is available too, because in this case defaults.inf will "lie". Opensuse will build with selinux setting defaults.inf with_selinux to true, but at run time won't find it.

So I think we need to use "lack of" the python-selinux tools as the hint we can't operate on the selinux environment in this case.

As for the restorecon force, I'm not so sure what's correct. Couldn't they fix the python-selinux module?

Metadata Update from @firstyear:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

3 years ago

My understanding is that availability of python-selinux or support of the force option is not guaranty, so the option the wrapper option looks good to me to adapt the installer to what is available at runtime

We also can't guarantee it's available on opensuse either because opensuse uses apparmor or
As for the restorecon force, I'm not so sure what's correct. Couldn't they fix the python-selinux module?

There is a PR opened to fix it (filed by @vashirov as mentioned in the ticket description), but there is no time line when this will actually get added and make it into RHEL/fedora, so for now we need to do something to fix the installer.

I want to clarify current situation with SELinux a bit.
lib389 is py3 only. RHEL7 doesn't have py3, we install it there from SCL. python-selinux is just python bindings generated by swig, and it doesn't have one-to-one compatibility between CLI tools provided by selinux package and the actual SELinux functions (hence that PR to add -F to python restorecon equivalent).

So we have a situation when we can't run any lib389 utils or tests on RHEL7, because lib389 imports selinux module which doesn't exist for this python package in SCL.

So I think we need to use "lack of" the python-selinux tools as the hint we can't operate on the selinux environment in this case.

Consider venv case - there might not be a python-selinux package, because we didn't inherit it from system packages and it can'be installed from pip (because it's not there, only system rpms). But we still would be able to operate on labels using SELinux CLI utils (if DS is built with_selinux).

Couldn't we just check with sestatus command whenever we would potentially need to touch SELinux? If the command does not exist or reports SELinux disabled, ignore (with an info message). Otherwise, the SELinux really is there, therefore we really should care and try our best with whatever tooling available (python-selinux first, but fallback to cli if that fails), and probably fail hard if that failed. BTW, e.g. as a contrib, we could do the same for AppArmor, as well.

@mhonek We can't guarantee that command exists on the system either, but selinux could be present ....

In hindsight, I think that us trying to fix selinux in the python is a huge mistake. We should just rely on system policy to be correct for our installations. By doing this, we have created a usability trap for ourselves. So controversial view: let's remove the selinux code because we should rely on the OS provided policy to be correct to create labels, ports etc.

The major trap for us the is port labelling on test execution. Perhaps we only try to touch selinux during tests?

Thinking about this more, perhaps there is a sysctl or /proc entry we can check?

@firstyear please, don't forget to leave a link to PR in the issue:
https://pagure.io/389-ds-base/pull-request/50124

Also, dscreate fails now (while skipping the port relabelling)

It happens here - https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/utils.py#_195

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/lib389/utils.py", line 193, in selinux_restorecon
    selinux.restorecon(slapd[path], recursive=True)
NameError: name 'slapd' is not defined

@spichugi I don't have a system with selinux on to test with, that's why I missed this :) I apologise and will send a pr fix shortly.

@spichugi I don't have a system with selinux on to test with, that's why I missed this :) I apologise and will send a pr fix shortly.

No problem! Thanks

Given that my pr has fixed this for systems that don't have selinux on them, is this issue still valid? I think only the "force" option is missing, but is that really necessary on the restorecon?

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3181

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

2 years ago

Login to comment on this ticket.

Metadata