[lmi-commits] [lmi] master 02f33b5 07/14: Don't rely on a nondefault umask

[Greg Chicares]

branch: master
commit 02f33b5697570d3794b06d7bfef4e010cc662f88
Author: Gregory W. Chicares <address@hidden>
Commit: Gregory W. Chicares <address@hidden>

    Don't rely on a nondefault umask
    
    Setting umask to 002 prevents problems with group permissions, but
    that's ugly. It seems that
      git clone --config core.SharedRepository=group
    should be sufficient, but it isn't.
---
 gwc/share_git1.sh | 25 ++++++++++++++++++-------
 gwc/share_git2.sh |  7 ++++---
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/gwc/share_git1.sh b/gwc/share_git1.sh
index d65e9b9..2b6dbe2 100755
--- a/gwc/share_git1.sh
+++ b/gwc/share_git1.sh
@@ -60,29 +60,40 @@ sudo --user=pulse git -C manual.git fetch
 
 # Second method: git-clone --bare --config core.SharedRepository=group
 
-# Instead of changing FETCH_HEAD's permissions below:
-umask 002
-
 chgrp audio .
 chmod g+ws .
 
 # The crux of this method is 'git clone':
 git clone --jobs=32 --bare --config core.SharedRepository=group 
https://github.com/wxWidgets/zlib.git
 
+# 'git clone' created its files with the intended group (so this:
+#   chgrp -R audio zlib.git
+# isn't needed), but it didn't make them group writable.
+# This is better than 'chmod -R g+s' (it affects only directories):
+find zlib.git -type d -exec chmod g+s {} +
+# Specifying 's' here would cause many 'S' occurrences in 'ls' output:
+#   chmod -R g+swX zlib.git
+# Specifying 'g+w' here would cause pack files to be group writable:
+chmod -R g=u zlib.git
+# There, 'g=u' doesn't override the earlier 'g+s'--see:
+#   https://lists.nongnu.org/archive/html/lmi/2020-03/msg00019.html
+
 # Permissions seem to be okay...
 find ./zlib.git ! -perm -g=w |sed -e'/objects\/pack/d'
-# ...though FETCH_HEAD doesn't yet exist:
+# ...but that's because FETCH_HEAD doesn't yet exist:
 ls -l ./zlib.git/*HEAD
 
 # This succeeds when run by owner:
 git -C zlib.git fetch
 
-# Permissions seem to be okay...
 find ./zlib.git ! -perm -g=w |sed -e'/objects\/pack/d'
-# ...including FETCH_HEAD:
+# Oops: FETCH_HEAD doesn't have group permissions:
 ls -l ./zlib.git/*HEAD
 
-# This succeeds (but not without 'umask 002' above):
+# This fails:
+sudo --user=pulse git -C zlib.git fetch
+# but it succeeds if FETCH_HEAD's permissions are fixed:
+chmod g+w zlib.git/FETCH_HEAD
 sudo --user=pulse git -C zlib.git fetch
 
 # The two methods produce somewhat similar results. Sizes:
diff --git a/gwc/share_git2.sh b/gwc/share_git2.sh
index 2c7b9ed..468d342 100755
--- a/gwc/share_git2.sh
+++ b/gwc/share_git2.sh
@@ -75,11 +75,12 @@ git clone --jobs=32 --config core.SharedRepository=group 
https://github.com/wxWi
 chgrp -R audio zlib
 # This is better than 'chmod -R g+s' (it affects only directories):
 find zlib -type d -exec chmod g+s {} +
-# Specifying 's' here causes many 'S' occurrences in 'ls' output:
-# chmod -R g+swX zlib
+# Specifying 's' here would cause many 'S' occurrences in 'ls' output:
+#   chmod -R g+swX zlib
 # Specifying 'g+w' here would cause pack files to be group writable:
 chmod -R g=u zlib
-# Why doesn't 'g=u' override the earlier 'g+s'?
+# There, 'g=u' doesn't override the earlier 'g+s'--see:
+#   https://lists.nongnu.org/archive/html/lmi/2020-03/msg00019.html
 
 # Permissions seem to be okay...
 find ./zlib ! -perm -g=w |sed -e'/objects\/pack/d'