Bug 1518631 - reconsider (drop) your "# special care for SELinux"
Summary: reconsider (drop) your "# special care for SELinux"
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: pki-core
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ade Lee
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-29 11:22 UTC by dac.override
Modified: 2020-10-04 21:37 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-05-28 19:35:14 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github dogtagpki pki issues 2980 0 None None None 2020-10-04 21:37:42 UTC

Description dac.override 2017-11-29 11:22:12 UTC
Description of problem:

You use "seobject". "seobject" is problematic since it hard codes identifiers that essentially ties it to "selinux-policy"

Even if it didn't, you still reference hard coded identifiers with it.

Example:

/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py:809

Please consider dropping your "special care for SELinux" (use of "seobject") as this essentially creates a hard dependency on specific selinux policy configuration. This forces in turn hard dependencies on consumers of dogtag (ipa server for example)

What value does the use of seobject really add? Can you do without it? Is there really a need to be aware of SELinux?

If there is, can you make failures on seobject non-fatal, by for example emitting warnings instead?

Version-Release number of selected component (if applicable):
pki-server-10.5.1-1.fc27.noarch

How reproducible:
run "/usr/sbin/pkispawn -s CA -f /tmp/tmpoohh38fw" on a Fedora system that has SELinux enabled, but that does not enforce "selinux-policy" (ie. a Fedora system with custom policy configuration)

Steps to Reproduce:
1.
2.
3.

Actual results:

2017-11-29T10:41:43Z DEBUG Starting external process
2017-11-29T10:41:43Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpoohh38fw
2017-11-29T10:41:44Z DEBUG Process finished, return code=1
2017-11-29T10:41:44Z DEBUG stdout=
2017-11-29T10:41:44Z DEBUG stderr=Traceback (most recent call last):
  File "/usr/sbin/pkispawn", line 39, in <module>
    from pki.server.deployment import pkiconfig as config
  File "/usr/lib/python2.7/site-packages/pki/server/deployment/__init__.py", line 31, in <module>
    from . import pkihelper as util
  File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", line 56, in <module>
    import seobject
  File "/usr/lib64/python2.7/site-packages/seobject.py", line 1047, in <module>
    class portRecords(semanageRecords):
  File "/usr/lib64/python2.7/site-packages/seobject.py", line 1049, in portRecords
    valid_types = list(list(sepolicy.info(sepolicy.ATTRIBUTE, "port_type"))[0]["types"])
IndexError: list index out of range

Expected results:


Additional info:

Comment 1 Ade Lee 2017-12-07 18:05:35 UTC
Is a reasonable workaround for you to run the PKI/IPA install with selinux disabled?  The install should complete successfully - and then you can re-enable it later.

The Dogtag selinux policy is part of the system policies (in selinux-policy).  If you are not using these policies and using a custom policy, you may run into issues you will need to address in your policy.

Comment 2 dac.override 2017-12-07 19:15:47 UTC
That would set a bad precedence. Besides you should be worried about this as well as hard coding customizable identifiers that could change over time potentially adds to your maintenance burden as well.

This SELinux awareness, or "# Special care for SELinux" as you call it, should likely not be needed in the first place.

In this state won't be using this component or anything that depends on it. Since I have the luxury to make that decision, I will not mind if you decide to ignore this request.

Comment 3 Fedora End Of Life 2018-02-20 15:30:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 4 Ben Cotton 2019-05-02 22:04:44 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Ben Cotton 2019-05-28 19:35:14 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.