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@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org