On Mon, 18 Jun 2018 at 12:18, Ian Malone <ibmalone@xxxxxxxxx> wrote:
[..]
> > Even if .bash_profile is not always read, .bashrc is read every time
> > a shell is started (OK, not "every time", but often enough). So for
> > example if I open a new tab in the terminal, or run some scripting plugin
> > from an editor, etc, the effect is the same as overwriting .bash_profile.
> >
>
> But these assume you are only attacking the shell. The system path is
> used to resolve commands started from the gui too, independent of
> bash.
In context of so called of "Nobody expects The Spanish Inquisition"
effect (understood as OOTB distro resources using executables and/or
data and/or configuration files which are not part of the regular
distribution) it is not only about targeting bash.
Many applications reads own env variables and passes $PATH down to
executed processes (this depends on variant exec() syscall used to
execute other processes). If application A will be executing script
interpreter which result will be used byt this A application it may
mean targeting exactly such application.
For example in case of have /usr/local/bin/id you can observe that
gnome-terminal started from command line and GUI menu are altere.
In other words this effect is literally spreads as well across most of
the /usr/share/application/*desktop files (just grep those files for
^Exec=).
Using in Exec= only binary name instead full path would be nothing bad
.. however this mixed with currently used $PATH really changes
everything!
And here is kind od "binary effect" of the "Nobody expects The Spanish
Inquisition" effect.
There are some number of properties of the current packages which
separately *does not increases risk*.
However, mixed with other packages properties on interacting with
those resources they are forming context with *non-zero risk*.
And it is one of those reasons why it was so easy to see those consequences :)
Simple .. most of the people do not expect that 0+0 suddenly will be
>=0. Isn't it?
Truth is that here works a bit different type of algebra.
Whoever knows mathematics above some level knows that it is nothing
unusual to have such outcome.
By define "+" operation as a+b+<cons> more times will be used "+"
operation than greated non-zero value will be even when a=b=0.
Another small exempla of this whole effect could be provided by
executing most of the python scripts.
In output of the "strace -e trace=file dnf" you will be able to find
fragments like:
stat("/usr/bin", {st_mode=S_IFDIR|0555, st_size=43016, ...}) = 0
stat("/usr/bin/dnf/__init__.cpython-36m-x86_64-linux-gnu.so",
0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf/__init__.abi3.so", 0x7ffee21f8970) = -1 ENOTDIR
(Not a directory)
stat("/usr/bin/dnf/__init__.so", 0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf/__init__.py", 0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf/__init__.pyc", 0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf", {st_mode=S_IFREG|0755, st_size=1942, ...}) = 0
stat("/usr/bin", {st_mode=S_IFDIR|0555, st_size=43016, ...}) = 0
stat("/usr/bin/locale/__init__.cpython-36m-x86_64-linux-gnu.so",
0x7ffee21f40f0) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/locale/__init__.abi3.so", 0x7ffee21f40f0) = -1 ENOTDIR
(Not a directory)
stat("/usr/bin/locale/__init__.so", 0x7ffee21f40f0) = -1 ENOTDIR (Not
a directory)
stat("/usr/bin/locale/__init__.py", 0x7ffee21f40f0) = -1 ENOTDIR (Not
a directory)
stat("/usr/bin/locale/__init__.pyc", 0x7ffee21f40f0) = -1 ENOTDIR (Not
a directory)
stat("/usr/bin/locale", {st_mode=S_IFREG|0755, st_size=63888, ...}) = 0
or lines like:
openat(AT_FDCWD, "/usr/bin/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such
file or directory)
openat(AT_FDCWD, "/usr/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat("/usr/bin/pyvenv.cfg", 0x7ffebc328a60) = -1 ENOENT (No such file
or directory)
stat("/usr/pyvenv.cfg", 0x7ffebc328a60) = -1 ENOENT (No such file or directory)
None of those paths are used in the dnf own code ..
If you know that exact application is using exact location to find
executables, scripting languages extensions/modules or configuration
files BEFORE checking well known paths in which other packages are
installing those types of resources you can use those locations to
alter how exact application is working without touching to many bells.
I've already mention about risk of altering of what for example
gcc/g++ is producing on Fedora build systems.
You can drop in /usr/local/bin most of the executables used during
building packages processes and you will be not be able to see
anything new/obvious looking on the build logs. It will be especially
easy in case of all packages build frameworks which are suppressing
verbosity level where are only logged details in a way like:
"CC: file.c"
"LD: prog"
This is why I've mention few times on this list about take care of
enable MAXIMUM possible verbosity level in build logs on Fedora build
systems.
Despite non-zero risk coming from above it is fact that checking all
those hardcoded paths and front paths from $PATH is pure waste of time
on build systems.
In other words it is not only about closing all those small (back)
doors but as well pure elegance to have distribution resources which
will be doing ONLY what they suppose to do. I'm almost sure that on
doing such cleanups it will be possible to solve some number of up to
now "untraceable" issues.
Devil sits in the details and as usually when people are not taking
care of such "small details" sooner or later "bad things happens".
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/AC4UKG43RRCGUAHKWDRS3LEADUO67ENC/
