Bug 1401442 - sed fails to modify file (symlink to /usr/) when running as staff_t
Summary: sed fails to modify file (symlink to /usr/) when running as staff_t
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sed
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Martisko
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-05 09:38 UTC by Jakub Jelen
Modified: 2018-01-23 21:46 UTC (History)
11 users (show)

Fixed In Version: sed-4.4-2.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-23 21:18:27 UTC
Type: Bug


Attachments (Terms of Use)

Description Jakub Jelen 2016-12-05 09:38:02 UTC
Description of problem:
I got failures when running fedpkg local using confined user (staff_t). The sed was unable to create a backup file from the symlink.

Version-Release number of selected component (if applicable):
sed-4.2.2-15.fc24.x86_64
glibc-2.24-3.fc25.x86_64
libselinux-2.5-13.fc25.x86_64

How reproducible:
Always

Steps to Reproduce:
$ cd /tmp/
$ ln -s /usr/share/libtool/build-aux/ltmain.sh ltmain.sh
$ sed -i.backup -e 's~compiler_flags=$~compiler_flags="-specs=/usr/lib/rpm/redhat/redhat-hardened-ld"~' ltmain.sh 

Actual results:
sed: couldn't open temporary file ./sed10n3jj: Permission denied
$ sudo ausearch -m AVC -ts recent
----
time->Mon Dec  5 10:32:58 2016
type=AVC msg=audit(1480930378.753:1064): avc:  denied  { create } for  pid=9902 comm="sed" name="sed10n3jj" scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file permissive=0


Expected results:
The backup file is created with the context of the symlink, not with the context of the symlink target, which is not allowed by the policy.

Additional info:

Comment 1 Fedora Admin XMLRPC Client 2016-12-05 13:55:16 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Jakub Jelen 2017-01-03 12:08:54 UTC
What is going on:

 * libtool
  * creates ltmain.sh as symlink to /usr/share/libtool/build-aux/ltmain.sh
  * it is ok, for using that file later
 * sed
  * try to modify this file (as part of build process in Fedora/RHEL)
  * the file is symlink, therefore sed creates a new file.
   * Why?
   * Is it expected and documented behavior?
  * sed is trying to preserve file attributes (including SELinux labels)
   * This is not a problem for normal users
   * For confined users, it fails, because they can not create files with this context (usr_t).

What can we do about that?
 * libtool should not create symlinks (we need to modify them a lot)?
 * sed should not preserve SELinux labels (bad)?
 * sed should use the SELinux labels from the symlink itself (unless it has --follow-symlinks switch)

The bottomline from our discussion is that we should go with the last option, but it most probably needs some changes in sed. What do you think? Does it make sense?

Comment 3 Kamil Dudka 2017-01-03 12:48:28 UTC
(In reply to Jakub Jelen from comment #2)
>   * the file is symlink, therefore sed creates a new file.
>    * Why?

It does not matter if the file is symlink or not.  sed -i always creates a new file.

>    * Is it expected and documented behavior?

Yes.  See the info documentation:

`-i[SUFFIX]'
`--in-place[=SUFFIX]'
     This option specifies that files are to be edited in-place.  GNU
     `sed' does this by creating a temporary file and sending output to
     this file rather than to the standard output.(1).

     This option implies `-s'.

     When the end of the file is reached, the temporary file is renamed
     to the output file's original name.

>   * sed is trying to preserve file attributes (including SELinux labels)
>    * This is not a problem for normal users

Sounds like a reasonable behavior to me.  One would not expect a file to change SELinux context after modifying it by sed -i.

>    * For confined users, it fails, because they can not create files with
> this context (usr_t).
> 
> What can we do about that?
>  * libtool should not create symlinks (we need to modify them a lot)?
>  * sed should not preserve SELinux labels (bad)?
>  * sed should use the SELinux labels from the symlink itself (unless it has
> --follow-symlinks switch)
> 
> The bottomline from our discussion is that we should go with the last
> option, but it most probably needs some changes in sed. What do you think?
> Does it make sense?

Yes, reading SELinux context from the symlink itself makes sense unless there is a (better) reason for using SELinux context of its target.

Comment 4 Petr Lautrbach 2017-01-03 13:01:52 UTC
(In reply to Kamil Dudka from comment #3)
> Sounds like a reasonable behavior to me.  One would not expect a file to
> change SELinux context after modifying it by sed -i.

But it's changed:

$ ls -Z ltmain.sh                                       
unconfined_u:object_r:user_tmp_t:s0 ltmain.sh

$ sed -i.backup -e 's~compiler_flags=$~compiler_flags="-specs=/usr/lib/rpm/redhat/redhat-hardened-ld"~' ltmain.sh

$ ls -Z ltmain.sh
system_u:object_r:usr_t:s0 ltmain.sh


> Yes, reading SELinux context from the symlink itself makes sense unless
> there is a (better) reason for using SELinux context of its target.

Given the described behavior, sed should definitely use a context from a symlink itself. The following change in sed/execute.c should fix it:

-         if (getfilecon (input->in_file_name, &con) != -1)
+         if (lgetfilecon (input->in_file_name, &con) != -1)

Comment 5 Paolo Bonzini 2017-01-03 16:14:47 UTC
I agree!  Please report the patch upstream as well to Jose E. Marchesi <jemarch@gnu.org>

Comment 6 Jakub Martisko 2017-01-04 08:49:55 UTC
I will look into it. Thanks for the patch.

Comment 7 Fedora End Of Life 2017-11-16 19:28:44 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 8 Jakub Jelen 2017-11-20 07:55:47 UTC
Any update? The same behavior is still present in Fedora 26.

Comment 9 Fedora Update System 2018-01-16 11:34:59 UTC
sed-4.4-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-10314cd3c0

Comment 10 Fedora Update System 2018-01-16 11:43:23 UTC
sed-4.4-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a7f395463a

Comment 11 Fedora Update System 2018-01-17 06:48:37 UTC
sed-4.4-4.fc27 has been pushed to the Fedora 27 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-2018-10314cd3c0

Comment 12 Fedora Update System 2018-01-17 06:57:11 UTC
sed-4.4-2.fc26 has been pushed to the Fedora 26 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-2018-a7f395463a

Comment 13 Fedora Update System 2018-01-23 21:18:27 UTC
sed-4.4-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2018-01-23 21:46:17 UTC
sed-4.4-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.


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