On Fri, 14.08.15 17:58, Matthew Miller (mattdm@xxxxxxxxxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
