Re: [lmi] Sharing files for two users

[Vadim Zeitlin]

On Fri, 14 Feb 2020 14:19:35 +0000 Greg Chicares <address@hidden> wrote:

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

 Unsurprisingly, I totally agree.

GC> I've successfully created an "lmi" group and added both our accounts
GC> to it.

 This looks like a perfectly reasonable thing to do to me.

GC> I figured it would make sense to change our primary GID to "lmi",

 Is this really necessary? IMHO being a member of "lmi" group is enough.
Then you just need to set the setgid (0o2000) bit (i.e. "chmod g+s") in the
permissions of the directories you want to share before creating them or
set it recursively and change the group recursively too if they had already
been created.

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

 As an aside, this is due to using "-" which resets the environment.
Without it, $SHLVL would be 2 (or, to be pedantic, 1 more than the current
one, which could be strictly greater than one if you're doing it from a
subshell in a chroot inside a container inside a virtual machine inside a
virtual reality simulator).

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

 This should work too, but I think it could be less confusing to have the
same users/groups inside and outside chroot.

GC> As a next step, I was thinking of replacing the above commit with:
GC> 
GC> +# Make directories and files created by this script available to other 
users.
GC> +umask 022
GC>    mkdir -p /srv/chroot/"${CHRTNAME}"
GC>    debootstrap "${CODENAME}" /srv/chroot/"${CHRTNAME}" 
http://deb.debian.org/debian/
GC> 
GC> which seems like a good idea:
GC>  - we're using 'schroot', in whose '.conf' file we can restrict
GC>    the chroot to our two user accounts only
GC>  - any file in this chroot should always be shared by both of us
GC> 
GC> Probably 'umask 027' would be even better. The last octal digit
GC> seems irrelevant if all users share the same primary GID, so I'd
GC> prefer to make the "lmi" group our GID at least within the chroot.

 This seems a bit too broad and potentially dangerous to me, some
directories are supposed to be owned by specific groups and while I can't
come up with any specific examples that would be relevant inside a chroot,
where you shouldn't have (m)any running daemons, I'd still apply "lmi"
group ownership on a more restrictive basis, just to be sure not to break
anything.

GC> One way to do that is apparently to execute
GC>   chmod 2750
GC> on the chroot's root directory (some regard any use of the setgid
GC> bit as a security concern, but here my goal is to set the chroot's
GC> GID to a group with the lowest privileges and the fewest members).
GC> Another way, since /srv/chroot is a separate HDD, is to use the
GC> 'grpid' mount flag. Does one of those approaches seem preferable
GC> to the other?

 I admit I hadn't even known about grpid mount option before, so I can't
really say anything about it. But it's global, while chmod is more
selective, so I'd use the latter on just the directories that need it.

 I could well be overcautious, of course, and perhaps using the mount
option would work just as well and be simpler. OTOH I still don't see any
advantage to using it compared to chmod on the chroot root directory: in
the latter case, you can at least see the setgid bit being set in the
filesystem, while in the former case the directories just magically have
different permissions/group ownership, which could well be confusing to
people not knowing about this mount option (who, as conclusively proven by
me above, do exist).

 Good luck,
VZ

pgpFtmjcKQH6J.pgp
Description: PGP signature