Same comand names in /usr/bin and /usr/sbin

[Lennart Poettering]

On Fri, 14.08.15 17:58, Matthew Miller (mattdm at fedoraproject.org) wrote:

> On Fri, Aug 14, 2015 at 07:24:16PM +0200, Lennart Poettering wrote:
> > Given that sbin is in $PATH for unprivileged users too the seperation
> > is really pointless, since it's now only the $PATH order which makes
> > this not explode.
> 
> Yeah; I have a halfhearted wish to rationalize what goes in sbin and
> what goes in bin. One approach would be to make sbin be commands that
> wouldn't normally be even in privileged users' $PATH — daemons and so
> on that should be launched by init. (Having crond in my path is just
> polluting the namespace.) But all of that is a lot of churn for
> something that's... not usually a problem.

Also, that ship has sailed a long time ago, when we added sbin to very
user's $PATH, not just root's...

There's the general problem that things which were initially intended
to be run only by root often are opened up later for unprivileged
clients, and if that happens you'd have to move the file from bin/ to
sbin/, but that breaks API, since the paths of many binaries are kinda
assumed to be API by many scripts. That then resulted in people
placing compat symlinks, so that /usr/sbin/tracepath for example
became a symlink to /usr/bin/tracepath so that both paths are
available.

In general: encoding privilige policy into the API through binary
paths is a really bad idea, as policy shouldn't be considered strict
API (or to be more precise: it should be allowed to open up policy --
while of course not necessarily to close it down later on), but paths
are.

Hence: we should say goodbye to the concept of separate bin/sbin, we
kinda did already by adding both to $PATH for all users, but we should
work on making this go away in the FS hierachy too, and replace sbin
by a symlink.

Lennart

-- 
Lennart Poettering, Red Hat