Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 453623 - sed -i changes security context
Summary: sed -i changes security context
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sed
Version: 5.2
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Vojtech Vitek
QA Contact:
URL:
Whiteboard:
Depends On: 524837
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-01 16:12 UTC by Petr Šplíchal
Modified: 2016-06-01 01:36 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-20 19:28:22 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Petr Šplíchal 2008-07-01 16:12:01 UTC
Description of problem:

After editing the nsswitch.conf file inside an RHTS test with sed -i I've
encoutered an AVC denial because of a wrong security context of this file (which
was caused by sed).

Version-Release number of selected component (if applicable):
sed-4.1.5-5.fc6

Steps to reproduce:
Run the following as an RHTS test

ls -Z /etc/nsswitch.conf
-rw-r--r--  root root system_u:object_r:etc_t /etc/nsswitch.conf

sed -i 's/^passwd.*$/passwd: files winbind/' /etc/nsswitch.conf
ls -Z /etc/nsswitch.conf

Actual results:
-rw-r--r--  root root system_u:object_r:etc_runtime_t /etc/nsswitch.conf

Expected results:
-rw-r--r--  root root system_u:object_r:etc_t /etc/nsswitch.conf

Additional info:

sed opens a temporary file, filters input into it and then renames/moves it to
the original, the last operation may cause the change in context.

What about creating the copy first and then filtering its contents into the
original? In this way there would be no change in security context and/or file
permissions.

Comment 1 Petr Machata 2008-07-01 16:46:56 UTC
Would you try to use sed -i -c instead of merely sed -i?

Comment 2 Petr Šplíchal 2008-07-14 12:31:25 UTC
Oh, I see. I didn't noticed this option. Anyway, shouldn't this behaviour be the
default one? Does anybody expect ownership and/or security context to be
modified when editing file in place with -i option? Is there any reason for
keeping the rename-like behaviour which happens without -c option? I'd suggest
to use -c always when running in in-place mode, which would automatically avoid
these unexpected changes.

Comment 3 Petr Machata 2008-07-14 13:18:34 UTC
I used the option because this was Fedora/RHEL-specific change in behaviour (my
concern was that copying potentially large file is something you may want to
avoid if possible).  I believe upstream sed already made this the default
behaviour, so as soon as new sed appears, we will follow the suit.

Comment 4 Paolo Bonzini 2009-06-25 18:08:17 UTC
(I'm speaking as the upstream maintainer).

The upstream version of sed introduced the --follow-symlinks option but it is an optional behavior; the --copy option was not taken (and will never be as long as I maintain sed).

The permission problem was fixed upstream by copying the owner and ACL, but not the security contexts.  I'm working on it right now.

Comment 14 RHEL Product and Program Management 2010-08-09 19:15:05 UTC
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 16 RHEL Product and Program Management 2011-09-23 00:29:03 UTC
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 17 Jake Kodak 2012-04-20 19:28:22 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. After consideration, Red Hat does not plan to incorporate the suggested capability in a future release of Red Hat Enterprise Linux. If you would like Red Hat to re-consider your feature request, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.


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