[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Greg Chicares
Subject: [lmi] Is 'chmod 771' merely silly, yet not harmful?
Date: Sun, 16 Feb 2020 21:50:37 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

Invoking 'install_redhat.sh' causes these commands to be executed:

  mkdir -p   /srv/chroot/"${CHRTNAME}"
  chgrp lmi  /srv/chroot/"${CHRTNAME}"
  chmod 2770 /srv/chroot/"${CHRTNAME}"
  umask 0007
  schroot --chroot=${CHRTNAME} --user=root --directory=/tmp ./lmi_setup_20.sh

and then, in 'lmi_setup_20.sh' (in the chroot, as the root user):

  #   https://wiki.debian.org/chroot#Configuration

  cat >/usr/sbin/policy-rc.d <<EOF
  exit 101

  chmod a+x /usr/sbin/policy-rc.d

which gives /var/chroot.../usr/sbin/policy-rc.d 0771 permissions
and ownership of root:lmi.

Other scripts in that directory generally have 0755 permissions
and are owned by root:root ('tzconfig', e.g.).

Vadim--Do you agree that this doesn't require any correction?
Nobody except root and members of group "lmi" should ever use
this chroot anyway, so in the "u g o" model, "o" for other
users is the empty set. It doesn't matter that group "lmi"
members can write this file, because they wouldn't want to.
I suppose I could
  chmod [...]/policy-rc.d --reference=[...]/tzconfig
but that breaks if we ever use BSD or if 'tzconfig' fails
to exist in this exact directory.

It does seem somewhat jarring that a file created by the
root user has ownership "root:lmi", but that's a natural
consequence of doing this before calling debootstrap:

  mkdir -p   /srv/chroot/"${CHRTNAME}"
  chgrp lmi  /srv/chroot/"${CHRTNAME}"
  chmod 2770 /srv/chroot/"${CHRTNAME}"
  umask 0007

and we do that because of this message from schroot's author:


If we were doing 'newgrp lmi' when entering the chroot,
then we might want to invoke 'newgrp' only for normal users.
However, we're not using 'newgrp' at all: we only change the
ownership of the root directory, when it's created, and I
see no compelling case for overriding that when we're the
root user.

Or maybe I'm missing something--but everything seems to
work just fine as it now stands.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]