strip looses original file ownership and file permissions
Franz Sirl
Franz.Sirl-kernel@lauterbach.com
Thu May 6 04:45:00 GMT 1999
At 12:48 06.05.99 , Franz Sirl wrote:
>Hi,
>
>I just verified that strip out of gas-990418 looses original ownership and
>permissions of a file.
>This is on glibc-2.1.1pre2, Linux-2.2.6 (PPC).
>
>Is this platform specific or does anybody else notice this?
After a quick browse through the source I came up with the following
untested patch. Does it look right?
Franz.
Index: rename.c
===================================================================
RCS file: /cvs/binutils/binutils/binutils/rename.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 rename.c
--- rename.c 1999/05/03 07:29:10 1.1.1.1
+++ rename.c 1999/05/06 11:36:14
@@ -163,29 +163,26 @@ smart_rename (from, to, preserve_dates)
#else
/* Use rename only if TO is not a symbolic link and has
only one hard link. */
- if (exists < 0 || (!S_ISLNK (s.st_mode) && s.st_nlink == 1))
+ if (exists == 0 && !S_ISLNK (s.st_mode) && s.st_nlink == 1)
{
ret = rename (from, to);
if (ret == 0)
{
- if (exists)
- {
- /* Try to preserve the permission bits and ownership of
- TO. First get the mode right except for the setuid
- bit. Then change the ownership. Then fix the setuid
- bit. We do the chmod before the chown because if the
- chown succeeds, and we are a normal user, we won't be
- able to do the chmod afterward. We don't bother to
- fix the setuid bit first because that might introduce
- a fleeting security problem, and because the chown
- will clear the setuid bit anyhow. We only fix the
- setuid bit if the chown succeeds, because we don't
- want to introduce an unexpected setuid file owned by
- the user running objcopy. */
- chmod (to, s.st_mode & 0777);
- if (chown (to, s.st_uid, s.st_gid) >= 0)
- chmod (to, s.st_mode & 07777);
- }
+ /* Try to preserve the permission bits and ownership of
+ TO. First get the mode right except for the setuid
+ bit. Then change the ownership. Then fix the setuid
+ bit. We do the chmod before the chown because if the
+ chown succeeds, and we are a normal user, we won't be
+ able to do the chmod afterward. We don't bother to
+ fix the setuid bit first because that might introduce
+ a fleeting security problem, and because the chown
+ will clear the setuid bit anyhow. We only fix the
+ setuid bit if the chown succeeds, because we don't
+ want to introduce an unexpected setuid file owned by
+ the user running objcopy. */
+ chmod (to, s.st_mode & 0777);
+ if (chown (to, s.st_uid, s.st_gid) >= 0)
+ chmod (to, s.st_mode & 07777);
}
else
{
More information about the Gas2
mailing list