GNU bug report logs - #36966
install-sh -s on 555 executable fails

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: bug-automake <at> gnu.org
Subject: install-sh -s on 555 executable fails
Date: Wed, 7 Aug 2019 15:50:53 -0600

(I'm not on this list, so please keep me in cc if need be.)

It seems that install-sh -s (what automake's install-strip target can
end up doing) fails if the original file doesn't have the owner-write
bit set:

cp /bin/cp /tmp/rx            # any binary will do
chmod 555 /tmp/rx             # make unwritable to owner
install-sh -s /tmp/rx /tmp/sx # try to install, with strip
-> strip: unable to copy file '/tmp/_inst.31092_'; reason: Permission denied
echo $?
-> 1

Although install-sh (version 2018-03-11.20, lines 224ff.) does some
stuff to ensure that umask will not clear an owner-writable bit in the
destination, that's not enough to make it owner-writable if it's not
already.

The only less-than-wonderful fix I could come up with is to explicitly
do chmod u+w if strip is being executed. I thought maybe it would be
worth trying the strip even if the chmod failed, hence the ; instead of
&&, but it's not something I feel strongly about. And maybe there is
some nicer way to do it altogether.

--- a/build-aux/install-sh
+++ b/build-aux/install-sh
@@ -461,7 +461,7 @@ do
     #
     { test -z "$chowncmd" || $doit $chowncmd "$dsttmp"; } &&
     { test -z "$chgrpcmd" || $doit $chgrpcmd "$dsttmp"; } &&
-    { test -z "$stripcmd" || $doit $stripcmd "$dsttmp"; } &&
+    { test -z "$stripcmd" || ($doit $chmodcmd u+w "$dsttmp"; $doit $stripcmd "$dsttmp") } &&
     { test -z "$chmodcmd" || $doit $chmodcmd $mode "$dsttmp"; } &&
 
     # If -C, don't bother to copy if it wouldn't change the file.


Wdyt? --thanks, karl.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.