Re: [lmi] Sharing git repositories

[Greg Chicares]

On 2020-03-04 21:32, Vadim Zeitlin wrote:
[...]
> GC> As for some-chroot/usr/sbin/policy-rc.d, we discussed that here:
> GC>   https://lists.nongnu.org/archive/html/lmi/2020-02/msg00015.html
> GC> and I think we concluded that 'chmod 755' was good there, although
> GC> upon careful re-reading it looks like you preferred '775', with
> GC> '7' in the middle so that system pseudo-users can run it, right?
> 
>  Did I? If so, I must have been confused because 775 is sufficient for
> this anyhow...

At that moment, this file had 0771 permissions due to a number of
changes that have since been reverted, and you said:

|  I'm not really sure about this. In principle, it doesn't seem implausible
| that some script might want to execute this script as some system user,
| using some system group (e.g. Debian-exim:mail to give a random example)
| and would fail to do its permissions because, even though it has "x" bit
| set for all users, it doesn't allow non-root non-lmi users to read it and
| shell scripts need to be readable in order to be executable. Of course,
| such scenario might never occur, but if it does, and some software package
| doesn't realize that it's being executed inside a chroot, it might result
| in some difficult to diagnose and debug problems.
| 
|  So I would feel better if the file had 0775 permissions.

and then, later on:

|  What I don't understand is why can't you just do "chmod 755" on it? Is

I committed 0755, but were you really arguing for 0775?

Hmmm...for a user like '_apt', even 0705 would suffice. The group
permissions mattered when I had stumbled into something like
  -rwxrwx--x 1 root lmi 19 Sep 11 23:30 /usr/sbin/policy-rc.d
through some adventures with the setguid bit and a weird umask,
and in that case I believe you were saying only that 0775 would
be better than 0771, i.e., that ...5 is better than ...1 . But
now that file looks like this:
  -rwxr-xr-x 1 root root 19 Sep 11 23:30 /usr/sbin/policy-rc.d
and the warnings about the '_apt' user have vanished, so I think
0755 is quite good enough, especially since it's just like this:
  -rwxr-xr-x 1 root root    34518 Sep 15  2018 /usr/sbin/adduser

> GC> Last and worst of all is the
> GC>   $(CHMOD) 750 $(cache_dir)/$@
> GC> line, committed a dozen years ago:
> GC>   git show 9fdaec5d0e7c
> GC> whose intention is to ensure that 'md5sum' is executable.
> 
>  Would it be horribly impolite to use this as an opportunity to remind you
> about https://github.com/vadz/lmi/pull/117, even if it's not directly
> related to this problem?

Thanks for reminding me. Pulling already-tested changes is easier
than trying to figure out all the ramifications of the classic
*nix permission model, so I think I'll attack that around 19 March
when it will provide a light and welcome diversion.

> GC>  - Why on earth did this ever seem necessary? It doesn't matter
> GC> on msw, which has no 'x' bit.
[...]
>  It could matter if you configured binfmt_misc to run .exe files
> automatically using Wine as I think the permissions are checked then, just
> as for native executables.

binfmt_misc always seemed like a security hole, to me, at least for
msw binaries.

>  OTOH if you can count on the file having correct permissions after the
> first run, i.e. when it is cached, wouldn't the following:
> 
>       test -x $(cache_dir)/$@ || $(CHMOD) 750 $(cache_dir)/$@
> 
> work too?

Thanks. I had conceived the idea, but feared that writing and validating
some test like
  if [ 'x' eq $(ls ... | sed ...) ]
would take too much time and bear only fragile, ugly fruit. I suppose
I must once have known about '-x', because:

  check_git_setup.sh:    [ -x ".git/hooks/pre-commit" ] || { printf 'fail [...]

but even that took me a while to find, because my first search attempt:
  grep -r '-x' * 2>&1 |less
didn't escape the hyphen. Such is my fluency in shell programming.