lmi
[Top][All Lists]
Advanced

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

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


From: Vadim Zeitlin
Subject: Re: [lmi] Is 'chmod 771' merely silly, yet not harmful?
Date: Mon, 17 Feb 2020 00:37:46 +0100

On Sun, 16 Feb 2020 21:50:37 +0000 Greg Chicares <address@hidden> wrote:

GC> Invoking 'install_redhat.sh' causes these commands to be executed:
GC> 
GC>   mkdir -p   /srv/chroot/"${CHRTNAME}"
GC>   chgrp lmi  /srv/chroot/"${CHRTNAME}"
GC>   chmod 2770 /srv/chroot/"${CHRTNAME}"
GC>   umask 0007

 I'm curious, what's the reason for using such restrictive umask for the
"other" users, especially knowing that they aren't supposed to be any?

GC> which gives /var/chroot.../usr/sbin/policy-rc.d 0771 permissions
GC> and ownership of root:lmi.
[...]
GC> Vadim--Do you agree that this doesn't require any correction?

 I'm not really sure about this. In principle, it doesn't seem implausible
that some script might want to execute this script as some system user,
using some system group (e.g. Debian-exim:mail to give a random example)
and would fail to do its permissions because, even though it has "x" bit
set for all users, it doesn't allow non-root non-lmi users to read it and
shell scripts need to be readable in order to be executable. Of course,
such scenario might never occur, but if it does, and some software package
doesn't realize that it's being executed inside a chroot, it might result
in some difficult to diagnose and debug problems.

 So I would feel better if the file had 0775 permissions.

GC> Nobody except root and members of group "lmi" should ever use
GC> this chroot anyway, so in the "u g o" model, "o" for other
GC> users is the empty set.

 Not quite, there are also system pseudo-users.

GC> It doesn't matter that group "lmi" members can write this file, because
GC> they wouldn't want to.

 This is also somewhat questionable: we don't run our systems as root
partially because this would allow us to accidentally change many files we
don't really want to write to. But in practice this seems unlikely to
happen, of course.

GC> I suppose I could
GC>   chmod [...]/policy-rc.d --reference=[...]/tzconfig
GC> but that breaks if we ever use BSD or if 'tzconfig' fails
GC> to exist in this exact directory.

 What I don't understand is why can't you just do "chmod 755" on it? Is
there something obvious I'm missing here? Because this looks like by far
the simplest way to ensure that no problems happen.

 Regards,
VZ

Attachment: pgpVkAxIGdu5j.pgp
Description: PGP signature


reply via email to

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