Hacker News Reader

Comment by codedokode | Hacker News Reader

If you link /bin to /usr/bin then all binaries will be available under /bin, and developers will hardcode paths like /bin/python3. This will make programs non-portable to other distributiobns with separate /bin and /usr/bin. The link farm doesn't have this problem.

View on HN

Did that end up becoming a problem in all the other distros using aliased directories, for example Fedora which has 10 years of experience with this scheme? An quick look on Fedora 35 with

  $ grep -rP "(?!(?=(?'a'[\s\S]*))(?'b'\/usr(?=\k'a'\z)|(?<=(?=x^|(?&b))[\s\S])))\/bin\/(?!(sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat))" /usr/bin

doesn't really show any objectionable binaries being referred to via /bin (I count those I excluded in the negative lookahead as certainly non-objectionable).

(I used the variable-length negative lookbehind [1] because I wanted to reduce false positives, but just scrolling through the results ended up being easier)

[1] http://www.drregex.com/2019/02/variable-length-lookbehinds-a...

Alternatively, a simple

   grep --binary-files=text -rP '(?<!/usr)/bin/(?!sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat)' /usr/bin

to also include binary files does the job as well.

I must be missing something, because I don't see how a link farm doesn't have the exact same problem.

In the case of symlinked directories we have:

  - the binary lives in /usr/bin/python3
  - /bin is a symlink to /usr/bin
  - /bin/python3 therefore refers to /usr/bin/python3

We can use either /usr/bin/python3 or /bin/python3.

In the case of a link farm we have:

  - the binary lives in /usr/bin/python3
  - /bin/python3 is a symlink to /usr/bin/python3

Again we can use either /usr/bin/python3 or /bin/python3.

As far as I can see, both methods allow insufficiently careful developers to hardcode the wrong paths. What am I missing?

> - /bin/python3 is a symlink to /usr/bin/python3

You don't symlink everything in /usr/bin to /bin, just "all regular files that have traditionally been in /bin" (per the article).

python3 has not traditionally been in /bin, so /bin/python3 would not be linked.

Ah, yes, thanks, that clears up things.

Ubuntu uses dpkg and have the merged /usr using the directory-symlink without any issues.

Also, I don't see how a folder filled with symlinks would prevent the problem that are you talking.

I wish two things happened... All OS's around the world implementing "#!python3" (or similar) as a shorthand to "#!/usr/bin/env python3", and in the meantime using #!/usr/bin/env to transition.

The reason that hasn't happened is because `#!` is a kernel level thing, but the `PATH` env is a userspace thing. I suspect even adding env parsing to the kernel would not be viewed as a favorable change…

It could literally be a shorthand for /usr/bin/env, actually delegating the PATH handling to user space. The path to /usr/bin/env could be a boot arg or runtime variable (sysctl). It could probably be implemented in Linux (without touching kernel code) via binfmt_misc. It's mostly a matter of people agreeing to do this.

Reply on news.ycombinator.com