On 2018-05-04 12:25, Przemek Klosowski wrote:
On 05/04/2018 09:42 AM, John Florian
wrote:
On 2018-05-04 09:33, Stephen John Smoogen wrote:
I would do so for the following reasons:
1. Even though the security arguments are weak, they are going
to be
checkmarks on audits which can't be changed for years.
2. When someone gets a "remove this and find out why the OS
did this"
it helps if they can point to an "official" change versus an
email.
This is an excellent point. Chasing the history of such changes
through myriad email is always frustrating, especially since
it's often inconclusive of what actually did happen.
Just checking my own PATH, I see some surprising things at the
front:
$ echo $PATH
/usr/libexec/python3-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
I love Sphinx and Qt, but what are they doing there ... at the
front? If nothing else, that seems an inefficient search order.
Yeah, caching will alleviate most of that, so why are they there
at all?
Yeah, I don't like it either. Even if there are reasons for those
two, it's a bad precedent---if every package did that, $PATH would
become unmanageable, and impossible to audit. Furthermore, the
way these two insert stuff into my $PATH is quirky/hacky: they
drop files into /etc/profile.d that cover csh and sh
- python-sphinx runs 'module load python-sphinx' from
/usr/share/modulefiles/python-sphinx/python2-sphinx which does
'prepend-path'
- qt just executes a shell script that manipulates $QT* and
$PATH
Since the main reason to mess with $PATH ordering is to
override same-named commands, I think we should have a guideline
that packages do not mess with path, or at least don't prepend
to it.
Such a guideline makes sense, if there's not already one. This
definitely violates the principle of least surprise. If someone is
using an alternative shell or they force set PATH rather than
modifying it, that could lead to abnormal behavior that doesn't help
anyone. I really appreciate that rpm won't let us overwrite files
of another package, but ought there be protection (probably not via
rpm) against displacing executables due to PATH hackery too?
Wouldn't same-named commands be better dealt with via the
alternatives system?
BTW, on my system, ktechlab also messes with $PATH but at least
it _appends_ /usr/libexec/sdcc to it. Still, I think sdcc should
just go to /bin...
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
|
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
