On Sun, Aug 16, 2015 at 8:03 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > 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. This is not such a problem if the files are identical. For "mock", "authconfig", and others trhat I personally mentioned, they are distinct binaries. I'd prefer to see that be discarded. If one is a binary that sommons the other with parameters, *rename* the target. > 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 Oh, my. I'm afraid I'm going to have to backfilll some history for reletavily new Linux developers. that unless you study some history, you won't understand this stuff. The original UNIX bootstrap tools lived in "/etc", namely the "dump" and "restore" tools and very little else. Later, as Linux was created, the "/" partition contained "/bin" and "/sbin", barely enough tools to run limited scripting and a other tools to be able to do the basic OS or restoration bootstrapping, tools that wouldn't fit in the old "/etc" hardcoded and limited disk space anymore. "/usr" was deployed later in the bootstrapping processes, and included far more site specific components. It included more than the most basic and universal bootstrapping toolkits. Both in "/sbin" on "/", and with "/usr/sbin" on "/usr" those tools were segregated because they were "dangerous* for ordinary users to play with, and potentially to confuse themselves and screw up the machine. The tools were still available, but they required specific selection to use. It's a basic violation of the ordinary segregation between "/bin" as ordinary user tools" and "/sbin" as sysadmin tools to start mixing them, and much more confusing to have the same program name in both. And it's frankly easy to avoid. "mock", for example, should rename "/.sbin/mock" to something else to avoid command line confusion. All that made clear, I'm going to get a bit persoal. I hope I can keep it clear an dpolite enough. Leonart, I'm afraid that it's very difficult to trust your opinion on anything involving ordinary filesystem layout. Your work with systemd makes it clear that you wish to discard much, if not all, of the existing configuration layout and File System Hierarchy to put it all under systemd and /run. This includes the sytemd re-arrangement of longstanding network configurations such as "/etc/resolv.conf" to a symlink to /run, the re-allocation of /meda to an ill-defined /run/media/username, I'm not saying these desires are not understandable, or evil. But it's very clear that you have other practices and goals in mind than a great deal of the existing Linux and UNIX community. And your suggested policies are often aimed at those broader goals, not aimed at solving the particular individual problem. Your comments above are one such example. *No one else* suggested discarding /sbin. Doing so will break decades of stable open source and free software. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
