+++ This bug was initially created as a clone of Bug #165799 +++ From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 Description of problem: When patching a file which is on the same partition that /tmp directory its security context is reset to tmp_t. Version-Release number of selected component (if applicable): patch-2.5.4-24 selinux-policy-targeted-1.25.3-12 How reproducible: Always Steps to Reproduce: 1. cd $HOME 2. echo example1 > example1; echo example2 > example2 3. ls -lZ example? -rw-r--r-- tometzky users user_u:object_r:user_home_t example1 -rw-r--r-- tometzky users user_u:object_r:user_home_t example2 4. diff -u example1 example2 | patch example1 patching file example1 5. ls -lZ example? Actual Results: -rw-r--r-- tometzky users user_u:object_r:tmp_t example1 -rw-r--r-- tometzky users user_u:object_r:user_home_t example2 Expected Results: -rw-r--r-- tometzky users user_u:object_r:user_home_t example1 -rw-r--r-- tometzky users user_u:object_r:user_home_t example2 Additional info: As can be seen by strace patch creates new version of a file as a temporary file in /tmp/ and then renames this file to the patched one and sets permissions to that of patched one causing that the file context will be tmp_t. If temporary and patched files are not on the same partition it fails to move and falls back to unlinking patched file, copying temporary file to the pathed and resetting permissions thus reseting it's context to default. I found this when I pathed a file in /etc and then realized that the daemon it was configuring does not start - it couldn't read its configuration. -- Additional comment from twaugh on 2005-08-12 12:39 EST -- Needs to use something like the mch_copy_sec() function from vim-selinux.patch. -- Additional comment from twaugh on 2005-12-08 07:34 EST -- Patch also does not preserve user/group ownership. This is just not how patch behaves. -- Additional comment from twaugh on 2005-12-20 09:55 EST -- *** Bug 167822 has been marked as a duplicate of this bug. *** -- Additional comment from twaugh on 2006-04-25 11:50 EST -- *** Bug 189890 has been marked as a duplicate of this bug. *** -- Additional comment from sds.gov on 2006-08-04 09:28 EST -- patch appears to apply chmod() to preserve mode, so that is analagous to preserving security context. -- Additional comment from sds.gov on 2006-08-04 09:36 EST -- Also appears to propagate the original file's mode to create file operations, which would be analogous to calling setfscreatecon() with the result of a getfilecon on the original prior to creating the output files. -- Additional comment from Christian.Iseli on 2007-01-19 19:13 EST -- This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks. -- Additional comment from tometzky.pl on 2007-01-20 04:11 EST -- Retested on patch-2.5.4-29.2.2 from FC6 - still applies.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Since this bugzilla is in a component that is not approved for the current release, it has been closed with resolution deferred. You may reopen this bugzilla for consideration in the next release.
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. This request will be reviewed for a future Red Hat Enterprise Linux release.
*** Bug 435526 has been marked as a duplicate of this bug. ***
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 "?".
This still seems to be broken in latest Fedora and presumably RHEL-6. Using the same example case above after disabling restorecond yields the same behavior except that the files are labeled user_tmp_r rather than just tmp_t. Should this be cloned for Fedora, or is this something you have no intention of fixing? An strace of the patch command in the steps to reproduce shows that it does invoke chmod() and chown() but not setxattr() on the newly created files.
Hmm...actually, behavior depends on whether you have a separate mount on /tmp. If /tmp and / are on the same filesystem, I end up with user_tmp_t on the patched file. If I have a separate /tmp mount (e.g. tmpfs mount), then the file gets re-created in $HOME and defaults to user_home_t as a result. But neither will actually preserve the original context - at no time do we seem to be calling setfilecon (->setxattr), whereas chown/chmod do seem to be called.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: SELinux file contexts were not preserved on patched files. This has been corrected.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0656.html