Re: problems with "make install" directory permissions

2020-07-27 Thread Frank Heckenbach
Karl Berry wrote:

> https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html
> 
> I can understand increasing permissions to allow +rx on installation
> directories, but why force 755, thus disallowing group writability?
> I've never understood this forcing of 755.

As the one who originally brought this up on bug-bison, I was only
referring to newly created install directories. Existing directories
should not have their mode changed, IMHO.

One can certainly argue for g+w. Since the directories are newly
created, one cannot look at the existing mode to decide whether to
do this. One could use the umask for that bit only, though this may
be a bit unintuitive. So a typical umask of 022 or 077 would result
in 755, but a umask of 002 or 007 would result in 775.

Regards,
Frank



Re: problems with "make install" directory permissions

2020-07-27 Thread Jim Meyering
On Mon, Jul 27, 2020 at 3:03 PM Paul Eggert  wrote:
>
> On 7/27/20 2:24 PM, Karl Berry wrote:
> >  https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html
> >
> > I can understand increasing permissions to allow +rx on installation
> > directories, but why force 755, thus disallowing group writability?
> > I've never understood this forcing of 755.
>
> I expect it was by analogy with regular files, where are already forced to use
> the equivalent of umask 22 when being installed.
>
> This could have been a decision I made years ago when modifying GNU 'install' 
> -
> I've forgotten the details. (No doubt it was a good decision at the time. :-)

>From what I recall, we deliberately avoid making installed things
group-writable because that would induce a security risk in
installations where more than one user is in the same default group.

If I install in such an environment (and don't override the group), I
don't want a peer to be able to modify what I've just installed.



Re: problems with "make install" directory permissions

2020-07-27 Thread Paul Eggert

On 7/27/20 2:24 PM, Karl Berry wrote:

 https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html

I can understand increasing permissions to allow +rx on installation
directories, but why force 755, thus disallowing group writability?
I've never understood this forcing of 755.


I expect it was by analogy with regular files, where are already forced to use 
the equivalent of umask 22 when being installed.


This could have been a decision I made years ago when modifying GNU 'install' - 
I've forgotten the details. (No doubt it was a good decision at the time. :-)




Re: problems with "make install" directory permissions

2020-07-27 Thread Karl Berry
https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html

I can understand increasing permissions to allow +rx on installation
directories, but why force 755, thus disallowing group writability?
I've never understood this forcing of 755.

I don't think Zack plans to release a new Automake.

Jim and I released automake-1.16.2 in March this year. We could make
another release, but it seems you have already dealt with it sufficiently.

As far as I know, there are no huge outstanding problems in automake. I
have been slowly trying to look at the backlog of bugs (since no one
else was, for years) and at least apply patches that have been
submitted. Tons remain. Of course other active contributors would be
most welcome. --thanks, karl.



Re: problems with "make install" directory permissions

2020-07-26 Thread Paul Eggert

[Following up on this thread in bug-bison:
https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html
]

On 7/26/20 7:09 AM, Frank Heckenbach wrote:

Maybe he can at least fix the permission problem. This should be a
smaller issue (at least compared to parallel configure).


I don't think Zack plans to release a new Automake. He's got enough on his plate 
just doing Autoconf.


That being said, we should be able to fix this particular problem by updating 
Automake master, propagating these fixes into Gnulib, and having Bison use the 
Gnulib versions. I did some of that that by patching Automake master's 
install-sh and mkinstalldirs files, resulting in the attached Gnulib patch which 
I've installed into Gnulib master. Hope this helps.
>From 1990797800153088f32029877f503f3157aad9ed Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 26 Jul 2020 15:17:46 -0700
Subject: [PATCH] autoupdate

---
 build-aux/install-sh| 115 +---
 build-aux/mkinstalldirs |  22 
 2 files changed, 61 insertions(+), 76 deletions(-)

diff --git a/build-aux/install-sh b/build-aux/install-sh
index 20d8b2eae..b34a8fc5a 100755
--- a/build-aux/install-sh
+++ b/build-aux/install-sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # install - install a program, script, or datafile
 
-scriptversion=2018-03-11.20; # UTC
+scriptversion=2020-07-26.22; # UTC
 
 # This originates from X11R5 (mit/util/scripts/install.sh), which was
 # later released in X11R6 (xc/config/util/install.sh) with the
@@ -69,6 +69,10 @@ posix_mkdir=
 # Desired mode of installed file.
 mode=0755
 
+# Create dirs (including intermediate dirs) using mode 755.
+# This is like GNU 'install' as of coreutils 8.32 (2020).
+mkdir_umask=22
+
 chgrpcmd=
 chmodcmd=$chmodprog
 chowncmd=
@@ -301,22 +305,6 @@ do
   if test $dstdir_status != 0; then
 case $posix_mkdir in
   '')
-# Create intermediate dirs using mode 755 as modified by the umask.
-# This is like FreeBSD 'install' as of 1997-10-28.
-umask=`umask`
-case $stripcmd.$umask in
-  # Optimize common cases.
-  *[2367][2367]) mkdir_umask=$umask;;
-  .*0[02][02] | .[02][02] | .[02]) mkdir_umask=22;;
-
-  *[0-7])
-mkdir_umask=`expr $umask + 22 \
-  - $umask % 100 % 40 + $umask % 20 \
-  - $umask % 10 % 4 + $umask % 2
-`;;
-  *) mkdir_umask=$umask,go-w;;
-esac
-
 # With -d, create the new directory with the user-specified mode.
 # Otherwise, rely on $mkdir_umask.
 if test -n "$dir_arg"; then
@@ -326,52 +314,49 @@ do
 fi
 
 posix_mkdir=false
-case $umask in
-  *[123567][0-7][0-7])
-# POSIX mkdir -p sets u+wx bits regardless of umask, which
-# is incompatible with FreeBSD 'install' when (umask & 300) != 0.
-;;
-  *)
-# Note that $RANDOM variable is not portable (e.g. dash);  Use it
-# here however when possible just to lower collision chance.
-tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$
-
-trap 'ret=$?; rmdir "$tmpdir/a/b" "$tmpdir/a" "$tmpdir" 2>/dev/null; exit $ret' 0
-
-# Because "mkdir -p" follows existing symlinks and we likely work
-# directly in world-writeable /tmp, make sure that the '$tmpdir'
-# directory is successfully created first before we actually test
-# 'mkdir -p' feature.
-if (umask $mkdir_umask &&
-$mkdirprog $mkdir_mode "$tmpdir" &&
-exec $mkdirprog $mkdir_mode -p -- "$tmpdir/a/b") >/dev/null 2>&1
-then
-  if test -z "$dir_arg" || {
-   # Check for POSIX incompatibilities with -m.
-   # HP-UX 11.23 and IRIX 6.5 mkdir -m -p sets group- or
-   # other-writable bit of parent directory when it shouldn't.
-   # FreeBSD 6.1 mkdir -m -p sets mode of existing directory.
-   test_tmpdir="$tmpdir/a"
-   ls_ld_tmpdir=`ls -ld "$test_tmpdir"`
-   case $ls_ld_tmpdir in
- d-?r-*) different_mode=700;;
- d-?--*) different_mode=755;;
- *) false;;
-   esac &&
-   $mkdirprog -m$different_mode -p -- "$test_tmpdir" && {
- ls_ld_tmpdir_1=`ls -ld "$test_tmpdir"`
- test "$ls_ld_tmpdir" = "$ls_ld_tmpdir_1"
-   }
- }
-  then posix_mkdir=:
-  fi
-  rmdir "$tmpdir/a/b" "$tmpdir/a" "$tmpdir"
-else
-  # Remove any dirs left behind by ancient mkdir implementations.
-  rmdir ./$mkdir_mode ./-p ./-- "$tmpdir" 2>/dev/null
-fi
-trap '' 0;;
-esac;;
+	# The $RANDOM variable is not portable (e.g., dash).  Use it
+	# here however when possible just to lower coll