Bug 524837 - Request to rebase sed to 4.2.1
Request to rebase sed to 4.2.1
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sed (Show other bugs)
5.5
All Linux
low Severity medium
: rc
: ---
Assigned To: Martin Bříza
BaseOS QE
: Rebase
Depends On: 514182
Blocks: 453623
  Show dependency treegraph
 
Reported: 2009-09-22 09:11 EDT by Paolo Bonzini
Modified: 2013-03-27 08:38 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
sed has been upgraded to release 4.2.1. When used without the "-i" option, the only effect of the upgrade will be improved performance and bug fixes. However, the release introduces the following visible changes to the behavior of "sed -i": * "sed -i" will always preserve the permissions, ACLs and security context of the original file, as long as the user can set them (for example, when a file is owned by root, a user will not be able to preserve ownership of the file after "sed -i"). Up until Red Hat Enterprise Linux 5.4, "sed -i" had a different behavior: it will never try to preserve ownership if the "-c" ("--copy") option was not given on the commandline; and it would always preserve the existing owner if the "-c" ("--copy") option was given. The new behavior is consistent with the existing documentation of "sed", with other Linux distributions, as well as with implementations of "sed" on other operating systems. The new release also fixes a minor security issue with "sed -i". The output of "sed -i" is now kept inaccessible to other users until it is complete.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-27 08:38:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Paolo Bonzini 2009-09-22 09:11:18 EDT
Rebasing to upstream release 4.2.1 would fix bugs 524835, 490473 (a regression; IT 276041) and 453623.  It would also fix several other bugs, including:

* hold-space is not reset between different files in -i and -s modes.

* sed 'i\' gives error message "sed: couldn't write -1 items to stdout: Success"

* errors in multibyte sequence processing

* sed does not accept NUL bytes for `.'

* fix parsing of s/[[[]//

* during "sed -i", incomplete files could be group/world executable.

The last of which could actually be a (minor) security problem

It would also remove the need for all Red Hat patches currently in the package (except one).

The proposed release has been in Fedora for around 2 months.
Comment 2 Paolo Bonzini 2009-09-22 10:19:48 EDT
Release Notes written, there are no documented procedures affected.
Comment 3 Paolo Bonzini 2009-09-22 10:19:48 EDT
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
sed has been upgraded to release 4.2.1.  When used without the "-i" option, the only effect of the upgrade will be improved performance and bug fixes.  However, the release introduces the following visible changes to the behavior of "sed -i":

* "sed -i" will not follow symbolic links by default; this is consistent with the behavior of "perl -i", with the existing documentation of "sed", with the behavior of "sed" on other Linux distributions, and also with the implementations of "sed" on other operating systems.  In case following symbolic links is desirable, the new version provides a "--follow-symlinks" command-line option.

* "sed -i" will always preserve the permissions, ACLs and security context of the original file, as long as the user can set them (for example, when a file is owned by root, a user will not be able to preserve ownership of the file after "sed -i").

Up until Red Hat Enterprise Linux 5.4, "sed -i" had a different behavior: it will never try to preserve ownership  if the "-c" ("--copy") option was not given on the commandline; and it would always preserve the existing owner if the "-c" ("--copy") option was given.

The new behavior is consistent with the existing documentation of "sed", with other Linux distributions, as well as with implementations of "sed" on other operating systems.

* Because of the above change, the "-c"/"--copy" option (while preserved for backwards compatibility) now has no effect.


The new release also fixes a minor security issue with "sed -i".  The output of "sed -i" is now kept inaccessible to other users until it is complete.   Previously, when a user operated under group A and edited a file with group B and mode 640, the output file was briefly readable by group A too.
Comment 4 john.haxby@oracle.com 2009-10-12 07:23:28 EDT
See also bug 527427 which deals with at least one of the errors in multibyte sequence parsing but which doesn't require a rebase to fix it.
Comment 5 RHEL Product and Program Management 2009-11-06 14:05:04 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 6 john.haxby@oracle.com 2009-11-09 04:37:41 EST
Can we have the fix for bug 527427 then please?
Comment 7 Paolo Bonzini 2010-06-02 09:50:56 EDT
If the rebase is done, we most likely won't be able to change the follow-symlinks behavior of RHEL5.  Luckily in upstream sed you can implement this behavior just with "sed -i /follow_symlinks/s/false/true/ sed/sed.c".
Comment 8 Paolo Bonzini 2010-06-02 09:50:56 EDT
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1,14 +1,9 @@
 sed has been upgraded to release 4.2.1.  When used without the "-i" option, the only effect of the upgrade will be improved performance and bug fixes.  However, the release introduces the following visible changes to the behavior of "sed -i":
 
-* "sed -i" will not follow symbolic links by default; this is consistent with the behavior of "perl -i", with the existing documentation of "sed", with the behavior of "sed" on other Linux distributions, and also with the implementations of "sed" on other operating systems.  In case following symbolic links is desirable, the new version provides a "--follow-symlinks" command-line option.
-
 * "sed -i" will always preserve the permissions, ACLs and security context of the original file, as long as the user can set them (for example, when a file is owned by root, a user will not be able to preserve ownership of the file after "sed -i").
 
 Up until Red Hat Enterprise Linux 5.4, "sed -i" had a different behavior: it will never try to preserve ownership  if the "-c" ("--copy") option was not given on the commandline; and it would always preserve the existing owner if the "-c" ("--copy") option was given.
 
 The new behavior is consistent with the existing documentation of "sed", with other Linux distributions, as well as with implementations of "sed" on other operating systems.
 
-* Because of the above change, the "-c"/"--copy" option (while preserved for backwards compatibility) now has no effect.
+The new release also fixes a minor security issue with "sed -i".  The output of "sed -i" is now kept inaccessible to other users until it is complete.-
-
-The new release also fixes a minor security issue with "sed -i".  The output of "sed -i" is now kept inaccessible to other users until it is complete.   Previously, when a user operated under group A and edited a file with group B and mode 640, the output file was briefly readable by group A too.
Comment 10 RHEL Product and Program Management 2010-08-09 15:15:01 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 12 RHEL Product and Program Management 2011-09-22 20:28:55 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 13 Martin Bříza 2012-06-06 09:16:15 EDT
The component has changed its owner to me, so I'm assigning the bug to myself.
Comment 14 RHEL Product and Program Management 2012-06-11 21:04:05 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 15 Phil Knirsch 2013-03-27 08:38:10 EDT
This request was evaluated by Red Hat Engineering for inclusion in a Red
Hat Enterprise Linux maintenance release.

Red Hat does not currently plan to provide this change in a Red Hat Enterprise
Linux update release for currently deployed products.

With the goal of minimizing risk of change for deployed systems, and in
response to customer and partner requirements, Red Hat takes a conservative
approach when evaluating enhancements for inclusion in maintenance updates
for currently deployed products. The primary objectives of update releases
are to enable new hardware platform support and to resolve critical
defects.

However, Red Hat will further review this request for potential inclusion
in future major releases of Red Hat Enterprise Linux.

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