On Sun, 16.08.15 12:57, Nico Kadel-Garcia (nkadel@xxxxxxxxx) wrote: > > 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. > > 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. Not really, /sbin was actually introduced originally to contain statically linked binaries. That's what "s" was supposed to mean, initially. Linux then later redefined that to mean "system". > "/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. Not really, this isn't about "dangerous". This is about "privileges" on Linux (i.e. "root-only," see FHS). UNIX had a concept of user priviliges since a long time... > 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. Hmm, so you are introducing a new "/.sbin" now? What's the point of that? Just use /usr/lib/<package> for private files that are not supposed to be called by anything else directly, and you are good. The difference between you and me is that I wan't to clean up the FHS by simplifying it, and enable new uses while doing so, while you just want to randomly introduce new directories without actually enabling anything new... > All that made clear, I'm going to get a bit persoal. I hope I can keep > it clear an dpolite enough. > > Lennart, 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. Hmm? I don't really follow what you are saying. Persistent admin configuration belongs under /etc, and not under "systemd" or "/run" or whatever you are saying. > This includes the sytemd re-arrangement of > longstanding network configurations such as "/etc/resolv.conf" to a > symlink to /run, I think you are misunderstanding something there. All I am proposing is that network management software does not make runtime changes to /etc each time you connect or disconnect to a WLAN. Because /etc is admin territory, should be considered static and persistent, and should hence not be manipulated constantly by system software without explicit request of the admin, during runtime. Or in other words: an admin should be able to mount /etc read-only, and the system should still be able to work (though of course not be able to change configuration), but I should still be able to connect to WLANs... Moreover, with everything we proposed there we always said that /etc/resolv.conf as real file trumps /etc/resolv.conf as symlink... The symlink is only added if nothing else was in place there yet. > the re-allocation of /meda to an ill-defined > /run/media/username, I was not really involved in that change (that's udisks). Although I think it makes a lot of sense, as it fixes security problems with regards to name clashes of labels between different users. > 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. Au contraire. How would that break "decades of stable open source and free software"? Sure consolehelper needs to be fixed first, but other than that? Suddenly all binaries are available in both paths. That means pretty much all scripts that hardcode one or the other path (maybe because ported over from another distro which sticks some binaries in a different path of the two than us) will work on our systems. That certainly *improves* compatibility with external software, not breaks any. But anyway, I think we can end the discussion here. You clearly have a problem with me personally, and I should probably not even have answered even once... 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
