Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1378323
Summary: | Conflicting labels for /usr/sbin/ldconfig and /usr/sbin/sln | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lukas Slebodnik <lslebodn> | ||||
Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> | ||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 26 | CC: | alan.christopher.jenkins, bugzilla, ctubbsii, dominick.grift, dwalsh, fedora, fedora, joe, luisf.rodriguez, lvrabec, mgrepl, michal.jnn, plautrba, sds, viorel.tabara | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | selinux-policy-3.13.1-225.6.fc25 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2018-05-29 11:47:19 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Lukas Slebodnik
2016-09-22 07:00:46 UTC
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. FWIW forcing a system relabel at boot will set /usr/sbin/ldconfig to bin_t. Once the system is back up a restorecon will reset the label to ldconfig_exec_t. You need to specifically restore the label of /usr/sbin/ldconfig. I tried a recursive restore of all labels under /usr and it updated the label on ldconfig twice (once for each name), leaving it with the generic label. # restorecon -rv /usr restorecon reset /usr/sbin/ldconfig context system_u:object_r:bin_t:s0->system_u:object_r:ldconfig_exec_t:s0 restorecon reset /usr/sbin/sln context system_u:object_r:ldconfig_exec_t:s0->system_u:object_r:bin_t:s0 # (In reply to David Hampton from comment #3) > You need to specifically restore the label of /usr/sbin/ldconfig. I tried a > recursive restore of all labels under /usr and it updated the label on > ldconfig twice (once for each name), leaving it with the generic label. > No that is not a problem. The problem that both files are the same thing due to hardlink sh# ls -li /usr/sbin/sln /usr/sbin/ldconfig 4182269 -rwxr-xr-x. 2 root root 1090216 Dec 9 18:51 /usr/sbin/ldconfig 4182269 -rwxr-xr-x. 2 root root 1090216 Dec 9 18:51 /usr/sbin/sln So it depends on the order of restoring context what will be result. sh# restorecon -v /usr/sbin/ldconfig /usr/sbin/sln restorecon reset /usr/sbin/ldconfig context system_u:object_r:bin_t:s0->system_u:object_r:ldconfig_exec_t:s0 restorecon reset /usr/sbin/sln context system_u:object_r:ldconfig_exec_t:s0->system_u:object_r:bin_t:s0 sh# restorecon -v /usr/sbin/sln /usr/sbin/ldconfig restorecon reset /usr/sbin/ldconfig context system_u:object_r:bin_t:s0->system_u:object_r:ldconfig_exec_t:s0 And because both files are the same thing(@see description of ticket + BZ1315476) they should have the same SELinux label. sh# matchpathcon /usr/sbin/sln /usr/sbin/ldconfig /usr/sbin/sln system_u:object_r:bin_t:s0 /usr/sbin/ldconfig system_u:object_r:ldconfig_exec_t:s0 Created attachment 1231227 [details]
Add context entry for /sbin/sln.
This should fix the problem. Untested.
I agree Lukas. I was specifically responding to comment 2 and didn't mention the ordering problem. selinux-policy-3.13.1-225.6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-66d634473a selinux-policy-3.13.1-225.6.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-66d634473a selinux-policy-3.13.1-225.6.fc25 does not fix the issue. After updating, I see: $ sudo restorecon -v /usr/sbin/sln restorecon reset /usr/sbin/sln context system_u:object_r:ldconfig_exec_t:s0->system_u:object_r:bin_t:s0 $ sudo restorecon -v /usr/sbin/ldconfig restorecon reset /usr/sbin/ldconfig context system_u:object_r:bin_t:s0->system_u:object_r:ldconfig_exec_t:s0 Loop. Repeat. Same results. $ sudo matchpathcon /usr/sbin/ldconfig /usr/sbin/sln /usr/sbin/ldconfig system_u:object_r:ldconfig_exec_t:s0 /usr/sbin/sln system_u:object_r:bin_t:s0 selinux-policy-3.13.1-225.6.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. This does not fix the problem. #rpm -q selinux-policy.noarch selinux-policy-3.13.1-225.6.fc25.noarch # matchpathcon /usr/sbin/ldconfig /usr/sbin/sln /usr/sbin/ldconfig system_u:object_r:ldconfig_exec_t:s0 /usr/sbin/sln system_u:object_r:bin_t:s0 Looks like the policy defines an entry for /sbin/sln and /sbin/ldconfig, but the real path is /usr/sbin, not /sbin, and there is no substitution defined in file_contexts.subs_dist for /sbin /usr/sbin (not sure if that would break anything). Yes we should add the links in subs_dist and fix any labels for /sbin and /bin to be /usr/bin and /usr/sbin. Surprised we did not do this years ago. *** Bug 1403012 has been marked as a duplicate of this bug. *** I can confirm this issue on current Fedora 26 beta: # ls -liZ /usr/sbin/ldconfig /usr/sbin/sln 5392 -rwxr-xr-x. 2 root root system_u:object_r:bin_t:s0 1112336 Jun 20 04:42 /usr/sbin/ldconfig 5392 -rwxr-xr-x. 2 root root system_u:object_r:bin_t:s0 1112336 Jun 20 04:42 /usr/sbin/sln Two success restorecon change the labels back and forth: # restorecon -rv /usr/sbin Relabeled /usr/sbin/ldconfig from system_u:object_r:bin_t:s0 to system_u:object_r:ldconfig_exec_t:s0 Relabeled /usr/sbin/sln from system_u:object_r:ldconfig_exec_t:s0 to system_u:object_r:bin_t:s0 # restorecon -rv /usr/sbin Relabeled /usr/sbin/ldconfig from system_u:object_r:bin_t:s0 to system_u:object_r:ldconfig_exec_t:s0 Relabeled /usr/sbin/sln from system_u:object_r:ldconfig_exec_t:s0 to system_u:object_r:bin_t:s0 Expected result: Second restorecon doesn't relabel anything. This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 '25'. 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 25 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. This issue is still applicable for F26. I have not tried F27. I see this fixed in F27. This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 '26'. 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 26 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. The /usr/sbin/sln executable is not present any more and is not being shipped by any package any more. For this reason, the bug cannot be reproduced any more. (In reply to Christian Stadelmann from comment #20) > The /usr/sbin/sln executable is not present any more and is not being > shipped by any package any more. For this reason, the bug cannot be > reproduced any more. Ahem ... rpm -qf /usr/sbin/sln glibc-2.26-27.fc27.x86_64 Looks to me like very much shipped. It is true /sbin is now a symlink to /usr/sbin so in package listing this shows up as /sbin/sln but ... I did not check how this is in F28. For better or wors rawhide ships at least /usr/share/man/man8/sln.8.gz although executable indeed seems to be gone from there. (In reply to Michal Jaegermann from comment #21) > > rpm -qf /usr/sbin/sln > glibc-2.26-27.fc27.x86_64 On Fedora 28 it is different: $ rpm -qf /usr/bin/sln error: file /usr/bin/sln: No such file or directory $ dnf provides /usr/bin/sln […] Error: No Matches found Sure, /usr/share/man/man8/sln.8.gz is present anyway. Maybe this is just a bug that /usr/bin/sln is not being shipped? On F28, I still have /usr/sbin/sln, but not sure why it is there, since it's no longer owned by anything and is not a symlink: $ rpm -q --whatprovides /usr/sbin/sln file /usr/sbin/sln is not owned by any package $ ls -alFd /usr/sbin/sln -rwxr-xr-x. 1 root root 922536 Mar 2 07:05 /usr/sbin/sln* There's still a man page, but I'm not sure it refers to the same binary (probably for bin/sln, not sbin/sln?): $ rpm -q --whatprovides /usr/share/man/man8/sln.8.gz man-pages-4.15-1.fc28.noarch And then there's this: $ sudo dnf provides '*/sln' Last metadata expiration check: 0:02:44 ago ... glibc-arm-linux-gnu-2.27-2.fc28.x86_64 : Cross Compiled ... Repo : fedora Matched from: Filename : /usr/arm-linux-gnu/sys-root/sbin/sln However, the conflict does appear to have gone away, since they are both marked ldconfig_exec_t now: $ sudo restorecon -v /usr/sbin/sln $ sudo restorecon -v /usr/sbin/ldconfig $ sudo matchpathcon /usr/sbin/ldconfig /usr/sbin/sln | column -t /usr/sbin/ldconfig system_u:object_r:ldconfig_exec_t:s0 /usr/sbin/sln system_u:object_r:ldconfig_exec_t:s0 Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 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. |