On 1/19/24 18:58, Robert Marcano via devel wrote:
On 12/28/23 1:25 PM, Robert Marcano wrote:
On 12/28/23 12:58 PM, Chris Adams wrote:
Once upon a time, Aoife Moloney <amoloney@xxxxxxxxxx> said:
Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)
Anything that depends on PATH entries is IMHO doomed to failure. There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it. Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.
Maybe replacing the /usr/bin related entries with a generic wrapper
that launch the best binary from the per architecture directories.
Note: This may affect a few programs that use argv[0] for something
meaningful.
The more I think about this, I am more convinced that /usr/bin installed
binaries must do this redirection too even in the case the PATH is
modified as this proposal states.
What about programs intentionally use absolute paths? These programs
will not take advantage of the optimizations of the binary they are
trying to start.
There many reasons for sometimes using an absolute path is agood idea,
like:
1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation
of the tool they call. I found a few on my installation, and their
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo,
CGI-BIN, etc.
Notice this PATH based optimization will only work when callers invoke
the program by name only, relative paths will not get optimized either,
a rare case but it could happen.
+100 to this.
Using something path-based will also exclude EVERYTHING started with a
shebang. I guess we didn't want to optimize those
Python/Perl/Ruby/whatnot scripts here?
A path based approach isn't anywhere near worth the mess it creates. A
humble opinion.
- Panu -
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
