After a security audit some years ago we changed all calls to external programs
in YaST to use the full path, i.e. from "foobar" to "/sbin/foobar".

The rationale was that this would prevent a potential attacker from
manipulating the $PATH to include some directory containing a malicious version
of the program, i.e. a "/my/hacked/foobar" with $PATH also containing
"/my/hacked".

With the transition from /bin to /usr/bin and /sbin to /usr/sbin that turned
out to be a bad idea since now we need to update those full paths in the YaST
code whenever any of those binaries makes that transition, i.e. it's moved from
/sbin to /usr/sbin.

Worse, if the transition is done in one supported product like Tumbleweed or
Leap, yet another one like SLES still uses the old path, we would have to
maintain different paths (and not forget to adapt them when that other product
makes that transition as well); or we would need to create our own fallback
logic to search all the possible paths which one to invoke.

But that fallback logic exists, and if handled correctly, it's just as secure
as using a full path; but more flexible and not fragile against tools being
moved from one system location to another: It's $PATH.

We need to make sure that $PATH only contains directories that are not
writeable by non-privileged users, and of course not "." (the current
directory) or any path that starts with "."; e.g.

  export PATH="/usr/sbin:/usr/bin:/sbin:/bin"

And we already do that in YaST code.

So we should migrate calls to external programs back to calling them without
the full path and use our secure $PATH instead.

For a more in-depth discussion, see also

  https://github.com/yast/yast-iscsi-client/issues/111