Re: [lmi] Is 'chmod 771' merely silly, yet not harmful?

[Greg Chicares]

On 2020-02-17 23:27, Vadim Zeitlin wrote:
> On Mon, 17 Feb 2020 23:12:34 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2020-02-16 23:37, Vadim Zeitlin wrote:
> GC> > On Sun, 16 Feb 2020 21:50:37 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> Invoking 'install_redhat.sh' causes these commands to be executed:
> GC> > GC> 
> GC> > GC>   mkdir -p   /srv/chroot/"${CHRTNAME}"
> GC> > GC>   chgrp lmi  /srv/chroot/"${CHRTNAME}"
> GC> > GC>   chmod 2770 /srv/chroot/"${CHRTNAME}"
> GC> > GC>   umask 0007
> GC> > 
> GC> >  I'm curious, what's the reason for using such restrictive umask for the
> GC> > "other" users, especially knowing that they aren't supposed to be any?
[...]
> GC> In this case, I read some articles claiming that a default 022 umask
> GC> is too liberal, and 027 is more secure. Accordingly, I chose 007 here
> GC> instead of 002. But tell me if you'd prefer 002 and I'll make it so.
> 
>  I don't really have any preferences here, considering that [...snip...]

I'm going to undo all these unclean workarounds and redo it the right way.
I believe I've found that the root cause was the line that set 'umask 077'
in etc/corporate_profile . Fixing that seems to make everything work: in
particular, it prevents the problem (see:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876703#20
) that started this wild goose chase--now, my normal unprivileged user can
enter the chroot successfully, and its root-directory permissions are the
same on the redhat server as on my debian machine:

  /srv/chroot/bullseye0[0]#ls -ld /srv/chroot/bullseye0             
  drwxr-xr-x 18 root root 4096 Sep 12 23:02 /srv/chroot/bullseye0

Accumulated workarounds had resulted in this mess:

  /srv/chroot/lmi_bullseye_1[0]#ls -ld *
...
  dr-xr-xr-x 282 root    root        0 Jul  1  2019 proc
  drwx--S---   3 root    root     4096 Feb 17 15:34 root
  drwxr-xr-x   4 root    root     4096 Feb 17 15:31 run
  lrwxrwxrwx   1 root    lmi         8 Feb 17 15:31 sbin -> usr/sbin
  drwxr-sr-x   2 root    root     4096 Feb 17 15:31 srv
  drwxr-xr-x   2 root    root     4096 Jul  9  2019 sys
  drwxrwxrwt   5 root    root     4096 Feb 17 16:10 tmp
  drwxr-sr-x  16 root    lmi      4096 Feb 17 15:33 usr

where the capitalization of 'S' in "drwx--S---" indicates insanity,
and fluttering between "root:root" and "root:lmi" ownership seems
capricious at best.

Furthermore, suppressing the silly workarounds and setting 'umask 022'
before regenerating the chroot makes this warning go away:

W: Download is performed unsandboxed as root as file 
'/var/lib/apt/lists/partial/deb.debian.org_debian_dists_bullseye_InRelease' 
couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

so the more restrictive umask actually defeated a security measure.