Bug 1401442

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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?

(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.

(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)

I agree!  Please report the patch upstream as well to Jose E. Marchesi <jemarch>

I will look into it. Thanks for the patch.

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.

Any update? The same behavior is still present in Fedora 26.

sed-4.4-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-10314cd3c0

sed-4.4-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a7f395463a

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

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

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.

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.