Re: [lmi] [lmi-commits] master d9f9099 2/2: Generally force group permissions to match user permissions

[Greg Chicares]

On 10/20/21 2:47 PM, Vadim Zeitlin wrote:
> On Wed, 20 Oct 2021 09:51:54 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> 
> GC> commit d9f9099b1ea701c5baa5fbeb21745b854ea3d01a
[...]
> GC> +# User and group permissions should be the same throughout $(prefix).
> GC> +# For each file that doesn't conform to that rule, list its name (to
> GC> +# make any systematic pattern clearer--for example, files generated
> GC> +# by autotools seem to ignore their directories' GIDs), and fix the
> GC> +# problem:
> GC> +find . \
> GC> +  -type f \
> GC> +  \( -perm -u+r ! -perm -g+r \
> GC> +  -o -perm -u+w ! -perm -g+w \
> GC> +  -o -perm -u+x ! -perm -g+x \
> GC> +  \) -print0 | xargs --null --verbose --no-run-if-empty chmod g=u
> 
>  I could be missing something, but the expression above doesn't seem to
> catch all the files for which user and group permissions differ as it
> doesn't cover group-writable but not user-writable files, for example.

Correct. A few lines below, a different command passes the octal
permissions of all files through 'sort -u', which should print a
very short list, where any oddity would be apparent.

My original idea was to use umask and the set-group-id bit so
that the rules above would be respected automatically. Later, I
added some lines, like those in the patch above, to force
compliance for files created by autotools; the idea isn't to
impose order globally by force, but to repair known flaws
caused by identified tools.

> Granted, it should be pretty rare to have _more_ permissions available to
> the group than to the user, but I still find it slightly confusing that the
> comment says that they should be the same, but the expression just checks
> for the group permissions including the user ones, so I think it might be
> worth updating the comment.

Agreed. Comment revised.

>  How to check that the user and group permissions are actually equal is an
> interesting exercise. The most straightforward solution I see is to use "ls
> -lR" and filter out the lines matching "^-(...)\1"

Some say that parsing 'ls' output is always suboptimal, at least
for piping into some command as opposed to prettifying output.
I'm striving to use 'find ... xargs' instead, so I prefer your
alternative here:

> or maybe use "find .
> -type f | xargs stat -c '%c %n' | grep -vE '^(.)\1'", not sure if there is
> a better way to do it.

...but that's a bigger hammer than I want to use here. As long
as autotools is the only offender, and the smaller hammer above
fixes the damage it calls, that seems okay.