[Top][All Lists]

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

Re: bashbug install mode

From: L A Walsh
Subject: Re: bashbug install mode
Date: Sun, 27 Nov 2016 14:26:32 -0800
User-agent: Thunderbird

Michał Górny wrote:

While scanning our systems for executables that are installed u-w, I've
noticed this specific mode is used for bashbug explicitly. Is there
a good reason for doing that?
   Doesn't it have execute permission?  But it seems semi normal
for a system-"executable" to be installed w/o write permissions
by "default", since, if the user *really* wants to delete it, they
can -- but the -w would at least give them a pause and they might
remember that it belongs to 'bash'.
However, I don't really see why those should be enforced for bashbug
when bash is regularly installed u+w.
   Now that, to me, is a bit odd.

   Looking at the makefile,  there are two installmode
constants -- w/installmode being 755 and installmode2 being 555.

   They are only used for 'bash' and 'bashbug' respectively.

   Weird.  I would have thought 555 for installing both would
be used.  FWIW, in the build dir, both are 775, which likely
has to do with my umask settings (002), as I manage permissions
more by group than by user.
I've also heard of SELinux issues with u+w executables. However, I'm
not aware if they're specific to binary executables or apply to
interpreted scripts as well.
   Well, technically, most modern cpus have the NX bit for
memory permissions, and except for special-need programs, areas
of memory that are RW *default* to not being executable.  So
settings of 'rwx' are inconsistent with the memory access.

It, also, might be argued, though, that for binaries, executables
are more often protected by utilities that create executables
(e.g. executables are not usually updated in place).  Whereas
it is, "more often", the case that text-based files (that may be
'executable') are updated, in-place, by more text-editing
applications.  Also, technically, "scripts" don't need to be
executable to be run -- only to have the kernel automatically
look at the 1st line for automatic invocation of an interpreter.
But one can always put the interpreter 1st, followed by the
scriptname and that will usually execute the script even if it
doesn't have the exec-bit set.

reply via email to

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