Bug 1378323 - Conflicting labels for /usr/sbin/ldconfig and /usr/sbin/sln
Summary: Conflicting labels for /usr/sbin/ldconfig and /usr/sbin/sln
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1403012 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-22 07:00 UTC by Lukas Slebodnik
Modified: 2019-04-29 09:18 UTC (History)
15 users (show)

Fixed In Version: selinux-policy-3.13.1-225.6.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-29 11:47:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Add context entry for /sbin/sln. (373 bytes, patch)
2016-12-13 14:04 UTC, David Hampton
no flags Details | Diff

Description Lukas Slebodnik 2016-09-22 07:00:46 UTC
Description of problem:
Files /usr/sbin/ldconfig and /usr/sbin/sln are the same binary
since glibc 2.23.90-28

sh$ rpm -q --changelog glibc | grep -A5 "2.23.90-28"
* Wed Jul 13 2016 Florian Weimer <fweimer> - 2.23.90-28
- Auto-sync with upstream master, commit
  f531f93056b34800383c5154280e7ba5112563c7.
- Add de_LI.UTF-8 locale.
- Make ldconfig and sln the same binary.  (#1315476)

sh$ ls -li /usr/sbin/ldconfig  /usr/sbin/sln
2386386 -rwxr-xr-x. 2 root root 1090208 Aug 11 13:57 /usr/sbin/ldconfig
2386386 -rwxr-xr-x. 2 root root 1090208 Aug 11 13:57 /usr/sbin/sln

But they have different SELinux labels and SELinux context depends on the order of processing files by restorecon 


Version-Release number of selected component (if applicable):
sh$ rpm -q glibc selinux-policy
glibc-2.24.90-2.fc26.x86_64
selinux-policy-3.13.1-214.fc25.noarch

How reproducible:
Deterministic

Steps to Reproduce:
1. matchpathcon /usr/sbin/ldconfig /usr/sbin/sln

Actual results:
/usr/sbin/ldconfig      system_u:object_r:ldconfig_exec_t:s0
/usr/sbin/sln   system_u:object_r:bin_t:s0


Expected results:
The same label (probably ldconfig_exec_t)

Comment 1 Fedora Admin XMLRPC Client 2016-09-27 15:04:22 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Viorel Tabara 2016-12-01 00:40:49 UTC
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.

Comment 3 David Hampton 2016-12-13 13:51:13 UTC
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
#

Comment 4 Lukas Slebodnik 2016-12-13 13:58:04 UTC
(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

Comment 5 David Hampton 2016-12-13 14:04:36 UTC
Created attachment 1231227 [details]
Add context entry for /sbin/sln.

This should fix the problem. Untested.

Comment 6 David Hampton 2016-12-13 14:09:30 UTC
I agree Lukas. I was specifically responding to comment 2 and didn't mention the ordering problem.

Comment 7 Fedora Update System 2017-01-08 22:21:35 UTC
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

Comment 8 Fedora Update System 2017-01-10 03:25:18 UTC
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

Comment 9 Christopher Tubbs 2017-01-10 04:41:32 UTC
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

Comment 10 Fedora Update System 2017-01-11 07:23:27 UTC
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.

Comment 11 David Hampton 2017-01-11 13:26:53 UTC
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

Comment 12 Stephen Smalley 2017-01-13 13:45:03 UTC
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).

Comment 13 Daniel Walsh 2017-01-13 14:53:18 UTC
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.

Comment 14 Michal Jaegermann 2017-04-24 13:40:05 UTC
*** Bug 1403012 has been marked as a duplicate of this bug. ***

Comment 15 Georg Sauthoff 2017-07-02 14:29:14 UTC
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.

Comment 16 Fedora End Of Life 2017-11-16 19:00:06 UTC
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.

Comment 17 Christopher Tubbs 2017-11-16 19:05:58 UTC
This issue is still applicable for F26. I have not tried F27.

Comment 18 Alan Jenkins 2017-11-16 19:29:18 UTC
I see this fixed in F27.

Comment 19 Fedora End Of Life 2018-05-03 08:01:30 UTC
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.

Comment 20 Christian Stadelmann 2018-05-21 20:49:33 UTC
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.

Comment 21 Michal Jaegermann 2018-05-21 21:16:43 UTC
(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.

Comment 22 Christian Stadelmann 2018-05-21 21:26:43 UTC
(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?

Comment 23 Christopher Tubbs 2018-05-21 22:56:24 UTC
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

Comment 24 Fedora End Of Life 2018-05-29 11:47:19 UTC
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.


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