[lmi] Sharing files for two users

[Greg Chicares]

To build lmi for a particular corporation, Kim and I have access to a
corporate RHEL server. This server is supposed to be dedicated to this
sole purpose; it has a couple dozen other user accounts, but those are
for individuals in corporate IT, and I've never seen them logged in.
The corporation sets 'umask 077' in its corporate defaults; thus, if I
build lmi, Kim can't see my binaries, and I'm trying to figure out how
we can share files routinely.

We're both sudoers, so we could just 'sudo su -' and run routinely as
root, but of course that's an atrocious way to implement file sharing.

I've successfully created an "lmi" group and added both our accounts
to it. Our primary group is something like "default_user_group": the
same group for both of us and apparently for other accounts, too.
I figured it would make sense to change our primary GID to "lmi",
but we don't have user-management privileges: we can't run 'useradd'
or 'usermod'. That seems unfortunate: there is necessarily some
proprietary product information on this server, and ideally it would
be restricted to us two, because no one else has a need to see it
(though that seems to have little practical significance, as every
other user probably logs in only to perform superuser tasks anyway).

I experimented with running
  newgrp - lmi
which does let us change GID. I don't much like that, though, because
it starts something that's like a subshell in that 'exit' returns to
a "parent" shell, yet unlike a subshell in that $SHLVL is 1.

OTOH, we're doing all our real work in a debian chroot, where we do
have the power to run 'useradd' etc., so maybe I should just ignore
the redhat base system's limitations and set the permissions we
really want on the chroot.

Recently I recreated that chroot, using the same scripts I had used
last year, but found that I couldn't log in to the chroot as my
normal user; lmi commit 6a4fa701dc of 20200208T23:24Z was a minimal
workaround for that problem:

    Make sure chroot's root directory is world-readable
  diff --git a/install_redhat.sh b/install_redhat.sh
[...]
   mkdir -p /srv/chroot/"${CHRTNAME}"
   debootstrap "${CODENAME}" /srv/chroot/"${CHRTNAME}" 
http://deb.debian.org/debian/
  +# Make sure chroot's root directory is world-readable--see:
  +#   https://lists.nongnu.org/archive/html/lmi/2020-02/msg00007.html
  +chmod 0755 /srv/chroot/"${CHRTNAME}"

That enabled me to log in, but Kim still can't read the files
I create in the chroot. Apparently the root cause is that the
corporation has set 'umask 077' in etc/profile customizations.

As a next step, I was thinking of replacing the above commit with:

+# Make directories and files created by this script available to other users.
+umask 022
   mkdir -p /srv/chroot/"${CHRTNAME}"
   debootstrap "${CODENAME}" /srv/chroot/"${CHRTNAME}" 
http://deb.debian.org/debian/

which seems like a good idea:
 - we're using 'schroot', in whose '.conf' file we can restrict
   the chroot to our two user accounts only
 - any file in this chroot should always be shared by both of us

Probably 'umask 027' would be even better. The last octal digit
seems irrelevant if all users share the same primary GID, so I'd
prefer to make the "lmi" group our GID at least within the chroot.
One way to do that is apparently to execute
  chmod 2750
on the chroot's root directory (some regard any use of the setgid
bit as a security concern, but here my goal is to set the chroot's
GID to a group with the lowest privileges and the fewest members).
Another way, since /srv/chroot is a separate HDD, is to use the
'grpid' mount flag. Does one of those approaches seem preferable
to the other?