[lmi] chroot's '/' must not have 0700 perms

[Greg Chicares]

[Posted for historical reasons. The problem may already be resolved.]

I tried this, which worked before (I'm sure of that, because these
commands were recalled from shell history that predates this problem):

/opt/lmi/src/lmi[0]$cd /opt/lmi/src/lmi
/opt/lmi/src/lmi[0]$sudo sh
REDACTED/opt/lmi/src/lmi$ ./install_redhat.sh >/home/REDACTED_USER/rhlog_$(date 
-u +%Y%m%dT%H%MZ) 2>&1

["REDACTED_USER" is the name of my account on this redhat server;
I've redacted literal occurrences of the name, and confirmed that
it matches the ${NORMAL_USER} variable]

Now, everything seems to work up to the last line here quoted
from that script:

schroot --chroot=${CHRTNAME} --user=root --directory=/tmp ./lmi_setup_20.sh
schroot --chroot=${CHRTNAME} --user=root --directory=/tmp ./lmi_setup_21.sh
# sudo -u "${NORMAL_USER}" ./lmi_setup_30.sh
schroot --chroot=${CHRTNAME} --user="${NORMAL_USER}" --directory=/tmp 
./lmi_setup_40.sh

The schroot commands with '--user=root' succeed, but the one
with '--user="${NORMAL_USER}"' fails:

schroot --chroot=${CHRTNAME} --user="${NORMAL_USER}" --directory=/tmp 
./lmi_setup_40.sh
+ schroot --chroot=lmi_bullseye_1 --user=REDACTED_USER --directory=/tmp 
./lmi_setup_40.sh
E: Failed to change to directory ‘/tmp’: Permission denied
I: The directory does not exist inside the chroot.  Use the --directory option 
to run the command in a different directory.

The debian chroot is, as expected, fully functional at this point.
(Configuring 'wine' and 'git' would be the next scripted steps, but
the debian system is complete.) Stepping back, I try to reproduce
the problem while signed in as my normal user, outside the chroot:

/home/REDACTED_USER[0]$schroot --chroot=lmi_bullseye_1 --user=REDACTED_USER 
--directory=/tmp
E: Failed to change to directory '/tmp': Permission denied
I: The directory does not exist inside the chroot.  Use the --directory option 
to run the command in a different directory.
/home/REDACTED_USER[2]$ls -ld /srv/chroot/lmi_bullseye_1/tmp
ls: cannot access /srv/chroot/lmi_bullseye_1/tmp: Permission denied
/home/REDACTED_USER[2]$sudo ls -ld /srv/chroot/lmi_bullseye_1/tmp
drwxrwxrwt 3 root root 4096 Feb  5 16:15 /srv/chroot/lmi_bullseye_1/tmp

That rules out any problem with the lmi scripts. On my debian machine,
the chroot's /tmp permissions are the same:

/home/greg[0]$ls -ld /srv/chroot/bullseye0/tmp 
drwxrwxrwt 9 root root 4096 Feb  7 13:28 /srv/chroot/bullseye0/tmp

but the schroot command succeeds (and the high inode number for '/'
demonstrates that I have successfully entered the chroot):

/home/greg[0]$schroot --chroot=chroot:bullseye0 --user=`whoami` --directory=/tmp
/tmp[0]$ls -di /
786435 /

Back on the redhat server, I log into the chroot, and examine its
/etc/passwd . As expected, my normal user is present, with exactly
the same name, uid, and gid as on the redhat base system.

Approaching the problem from a different angle, I compared the
current log to one from 2019-10-10. They're substantially
identical through the failing 'schroot' command, and that
command itself is exactly identical in both. Both have the
same version of 'schroot':
  Package schroot-1.6.10-7.el7.x86_64 already installed and latest version

Could there be some difference in the logs that actually is important
but seems not to be? Ignoring
 - timestamps, which naturally must differ
 - slightly newer versions of some debian packages resulting
     from apt-get dist-upgrade
 - "Download is performed unsandboxed..."[1], which seems benign
we see (lmi commit 79d1e7377 of 2019-10-10T23:21:10+00:00) that
both 'users' and 'groups' were double-quoted in the old log
'rhlog_20191010T1303Z' (about ten hours before commit 79d1e7377).
The old log shows the schroot command succeeding. However,
reinserting the double quotes results in this on the server:

  schroot --chroot=chroot:bullseye1 --user=`whoami` --directory=/tmp
  E: Access not authorised
  I: You do not have permission to access the schroot service.
  I: This failure will be reported.

whereas reverting (removing the double quotes) results in:

  E: Failed to change to directory '/tmp': Permission denied
  I: The directory does not exist inside the chroot. Use the
    --directory option to run the command in a different
    directory.

The 79d1e7377 commit message says:
  Prefixing that failing command with 'sudo' makes it work as expected.
However:
  sudo schroot --chroot=chroot:bullseye1 --user=REDACTED --directory=/tmp
produces the same "...'/tmp': Permission denied" outcome.

Taking a completely different approach...a web search for the error
message leads to:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876703
| What are the permissions on the root directory of the chroot?

redhat machine:

sudo ls -ld /srv/chroot/lmi_bullseye_1
drwx------ 18 root root 4096 Feb  5 16:12 /srv/chroot/lmi_bullseye_1

debian machine:

$ls -ld /srv/chroot/bullseye0/                 
drwxr-xr-x 18 root root 4096 Sep 12 23:02 /srv/chroot/bullseye0/

so we want chmod 755:

$stat -c '%a %A %U %G %n' /srv/chroot/bullseye0
755 drwxr-xr-x root root /srv/chroot/bullseye0

Testing:

/home/REDACTED[0]$sudo stat -c '%a %n' /srv/chroot/lmi_bullseye_1/tmp
1777 /srv/chroot/lmi_bullseye_1/tmp
/home/REDACTED[0]$sudo stat -c '%a %n' /srv/chroot/lmi_bullseye_1/
700 /srv/chroot/lmi_bullseye_1/
/home/REDACTED[0]$sudo chmod 0755 /srv/chroot/lmi_bullseye_1/
/home/REDACTED[0]$sudo stat -c '%a %n' /srv/chroot/lmi_bullseye_1/
755 /srv/chroot/lmi_bullseye_1/
/home/REDACTED[0]$sudo ls -ld /srv/chroot/lmi_bullseye_1/
drwxr-xr-x 18 root root 4096 Feb  5 16:12 /srv/chroot/lmi_bullseye_1/
/home/REDACTED[0]$
/home/REDACTED[0]$schroot --chroot=lmi_bullseye_1 --user=`whoami` 
--directory=/tmp
REDACTED@ALSO_REDACTED:/tmp$

Now I'll update the build-everything script and run it again.

---------

[1] "Download is performed unsandboxed..."

This report:
     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930667
was closed because the problem seems to be permissions rather
than 'apt'. Observe:

/home/greg[0]$cat /etc/debian_version 
10.2
/home/greg[0]$ls -ld /var/lib/apt/lists/partial 
drwx------ 2 _apt root 4096 Jan 26 23:06 /var/lib/apt/lists/partial
/home/greg[0]$ls -ld /var/lib/apt/lists        
drwxr-xr-x 4 root root 4096 Jan 26 23:06 /var/lib/apt/lists

Perhaps /var/lib/apt/lists/ should be owned by '_apt'. See:
  https://groups.google.com/forum/#!topic/linux.debian.user/sHhDsvTkxgQ