From: Tomas H. <to...@lo...> - 2016-08-30 07:36:28
|
Hi, Bruno Haible <br...@cl...> writes: > Differences between /bin/<prog> and <prog> in general: > > * You can be sure that /bin/<prog> exists; you don't need to handle > the case that PATH has been set in such a way that <prog> is not found. counterexample: $ ls -al /bin total 8 drwxr-xr-x 2 root root 4096 2016-08-25 09:44 . drwxr-xr-x 17 root root 4096 2016-05-29 00:28 .. lrwxrwxrwx 1 root root 63 2016-08-25 09:44 sh -> /nix/store/9zv8ph14qa9x685ig6agxy9yzxcapfar-bash-4.3-p42/bin/sh $ This is on NixOS so your assertion is valid only for systems that follow certain convention, e.g. <https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard>. Any dependency on external programs comes with many assumptions and no guaranties. For example, using /bin/<prog> harcodes the assumption about FHS, among others. > * PATH is under user control. If you use <prog> you need to handle > the case that <prog> is not executable, a dangling link, or it could > be slowed down on an NFS volume etc. Using /bin/<prog> has exactly the same problems as well as harcoding FHS assumption. > The only good argument against /bin/<prog> that I can see is that some > modern distros, like GNU GuixSD, construct PATH based on symbolic > links. But I would expect them to have a mechanism to simulate a /bin > directory in some way. Yes. They don't simulate the /bin directory. They patch away the hardcoded paths and construct the environment in such a way, that the program uses the right dependencies. Or, they replace the hardcoded path with the correct path of the dependency. So from the point of those modern distros, I think it is slightly better not to hardcode the FHS assumption so that they do not have to patch the sources. However, even if the path stays hardcoded, it is a solved problem (I have clisp running here). Sam Steingold <sd...@gn...> writes: > running external programs without a full path is a security risk. What is the reasoning behind this assertion? Tomas |