Re: /bin/pwd

[Daniel J. <dan...@gm...>]

These little changes spawned quite a lot of discussion ...

I need these changes (removing the absolute paths) because I - running
NixOS - don't have pwd, cat etc. in /bin/. That's the main reason for
these commits. If it is _really_ necessary to keep the absolute paths
then I can keep these changes locally. Now I really don't want to
offend anyone, so please don't get upset by the following, but I like
being honest and ...


> * if clisp executes "pwd" and you have, say, "~/bin" in your $PATH
> * before "/bin" and * a malicious actor plants an executable named
> * "pwd" into "~/bin", then you will run that executable as yourself.

... I'm a bit annoyed by this:

What if a malicious actor plants an "exec modified_shell" into the
shell's init file that rewrites all calls to /bin/pwd to a malicious
binary?

What if there's a rootkit running? What if the shell is running within
a proot (usermode chroot) session that mounts a directory with
malicious binaries to /bin?

What if a malicious actor does this:
alias cd='some_command_involing_rm_rf_and_a_home_directory'

Even if we "secure" pwd and cat, what about: gcc, ranlib, ar, mv, cp,
ln, make, ... ? Do we want to hardcode these paths, too?


The point is: It is none of our business. If a malicious actor has
that much control over the users environment, then all hope is lost
eitherway. Moreover, we're talking here about the build system, and
not about software to counteract such a security breach (this wouldn't
make sense to run from the user environment eitherway).

The whole purpose behind things like $PATH is to be able to configure
which binaries to use. What if the user is a non-root user on some
server, and the system /bin/pwd has a bug because of a wrong system
time but the user has a working pwd in ~/bin ?(sounds unlikely? I've
already been in that position ...)

What if the user needs special versions of pwd, mv, cp and such
because the sources live on a non-standard network filesystem that
cannot be mounted, but can be accessed using these commands?
(Unlikely, true, but we just don't know).

The user should provide external dependencies. The build system tries
to find them, or let's the user otherwise provide the location of
these dependencies (for example by setting $PATH ..)

We could also think this further: We depend on libsigsegv. Why let the
user specify where to find it when we can also download it directly
during the build process and put it into a known location? Why not
download a libc of our choice? Or a compiler? ...


That said, all of this (except the /bin/cat in the test) will become
pointless because as soon as we switch to an autotools based build
system, because it will do the right thing anyway.


The discussion also seems to carry a bit much of emotion, so I hope I
don't make things worse, but I'd like to come back to my original
question:

> Why do we need the physical (not logical, i.e. without the
> symlinks) path, though?

Rephrasing: Why do we want to compare directories?