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.
Would you try to use sed -i -c instead of merely sed -i?
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.
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.
(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.
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.
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.