Re: /bin/pwd

Hi,

Bruno Haible <[email protected]> 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 <[email protected]> writes:
> running external programs without a full path is a security risk.

What is the reasoning behind this assertion?

Tomas

------------------------------------------------------------------------------
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel