Re: /bin/pwd

[Jan S. <ha...@st...>]

On Aug 30 17:57:06, dan...@gm... wrote:
> 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.

You are suggesting to discard the standard, portable way of doing things
in order to accommodate one Frankenstein system.
Not that I have any say in this, but no way.

> If it is _really_ necessary to keep the absolute paths
> then I can keep these changes locally.

How about you locally make a /bin/pwd symlink
and leave things like they should be?

> > * 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?

[snip rest of rant about how we are doomed anyway
if attacker can replace binaries]

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

I don't think that security concerns are the main issue here:
the point of calling /bin/pwd is not to "secure" pwd, but this:
if you want to know the current working directory in a script,
why would you call anything else but /bin/pwd?


BTW:

  $ uname -a
  SunOS fray1 5.11 11.3 sun4v sparc SUNW,SPARC-Enterprise-T5120
 
  $ find /bin/ /usr/bin/ /usr/xpg* -name pwd\*
  /bin/sparcv9/pwdx
  /bin/pwdx
  /bin/pwd
  /usr/bin/sparcv9/pwdx
  /usr/bin/pwdx
  /usr/bin/pwd

> The whole purpose behind things like $PATH is to be able to configure
> which binaries to use.

Not here. The purpose of calling pwd(1) in a script such as tests/*tst
is to get a result guaranteed by /bin/pwd to be what you expect.
What's there to "configure" about this?

> 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 ...)

Ah, another Frankenstein system we should accomodate
instead of doing the obvious, standard thing.

(BTW, how exactly would wrong system time
influence the behaviour of pwd(1)?)

> 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).

Hm, yet another Frankenstein. If you have a cp(1) that cannot cp
or a mv(1) that cannot mv, fix _that_ before writing any scripts.

> 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?

Because libsigsegv can be installed anywhere in the system,
unlike standard binaries like pwd(1).

	Jan