summaryrefslogtreecommitdiff
path: root/NEWS
diff options
context:
space:
mode:
authorPaul Eggert <eggert@cs.ucla.edu>2006-12-07 08:10:35 +0100
committerJim Meyering <jim@meyering.net>2006-12-07 08:10:35 +0100
commitfc92148eac1cd2f8a5e99b3facc21e630e815bef (patch)
treee7f6086bd126eb980877eea391b69ec1aad3b614 /NEWS
parenta4f7b723f0723ec17b48ae25f0a218adcab2ff54 (diff)
downloadcoreutils-fc92148eac1cd2f8a5e99b3facc21e630e815bef.tar.xz
cp -p now clears special bits if it fails to preserve owner or group
* NEWS: Document the cp -p fix for special bits. * src/copy.c (set_owner): Now returns a three-way result, so that the caller can clear the special bits. All callers changed. (copy_reg): Don't set the special bits if chown failed. (copy_internal): Likewise. * tests/cp/special-bits: Test this fix. Signed-off-by: Jim Meyering <jim@meyering.net>
Diffstat (limited to 'NEWS')
-rw-r--r--NEWS8
1 files changed, 8 insertions, 0 deletions
diff --git a/NEWS b/NEWS
index fad4e1c63..1ce50f85a 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,14 @@ GNU coreutils NEWS -*- outline -*-
** Bug fixes
+ When cp -p copied a file with special mode bits set, the same bits
+ were set on the copy even when ownership could not be preserved.
+ This could result in files that were setuid to the wrong user.
+ To fix this, special mode bits are now set in the copy only if its
+ ownership is successfully preserved. Similar problems were fixed
+ with mv when copying across file system boundaries. This problem
+ affects all versions of coreutils through 6.6.
+
cp --preserve=ownership would create output files that temporarily
had too-generous permissions in some cases. For example, when
copying a file with group A and mode 644 into a group-B sticky