On Thu, 08 Sep 2011 22:40:07 +0200 Michael Schreckenbauer <grim...@gmx.de> wrote:
> Am Donnerstag, 8. September 2011, 22:05:36 schrieb Alan McKinnon: > > On Thu, 08 Sep 2011 19:11:04 +0200 > > > > Michael Schreckenbauer <grim...@gmx.de> wrote: > > > > Then design the correct solution and implement it. If it's > > > > technically sound, it will prevail. I think it's a rather > > > > complicated problem with a non trivial solution, but the code is > > > > there if you feel like give it a try. > > > > > > Where did I write, that I am in the position to write such a > > > beast? I only take the freedom to name this a design flaw in udev. > > > It needs things from userspace, which are not yet available at the > > > point it requests them. An initramsfs is a workaround for this, > > > not a proper fix. > > > > If that is the argument from the udev devs you just quoted, then I > > do not understand it at all. > > It's my understanding, that this is their point. > > > Why can there not be a restriction that udev may only run code in > > the traditional / space (i.e. it will not attempt to run code in > > the /usr or /home spaces)? > > Yes. I really wonder, why we have /bin, /sbin and /lib The / partition may contain, at a absolute minimum, only that software required to boot and start userspace. So you find mount, fsck and sh in there. Everything else that non-root users use routinely (and not required to boot and repair) is in /usr. The software on / splits into three logical categories: - code that only works when run as root in /sbin. Example: fsck - code that is required on /, but regular users may use it under normal circumstances, it cannot go in /sbin so it is in /bin. Example: mount - libraries, which go in /lib The distinction between bin and sbin is traditional and not really required. It comes from the days when resources were scarce and /bin and /sbin were a little too big combined to work efficiently. A nice side-effect is that /sbin could go in root's PATH so the code in it would not clutter up the user's space with tab-completion and which. This is not a security feature, just a convenience (same thinking as dot files). The same three directories exist under /usr, where the system package manager will maintain the contents. And the same three directories exist under /usr/local which is where the local sysadmin installs stuff he compiles himself and where the package manager won't touch it. Pre-compiled binaries such as Skype, Opera and database products go in /opt, completely contained in one directory tree (much like Windows and MacOS). This too is good as you can remove an entire product's files by deleting one directory tree without having to worry about all the places the files might be (the package manager is usually of no help in this). > > > Device nodes are a root function; root is the only user that should > > dictate how device nodes are created; root is the only user that can > > normally write to / and thereby create udev's rules and rulesets. > > > > In what valid way does access to /usr become something that udev > > may be required to support? > > As udev is able to run arbitrary scripts, there *might* be some code, > that requires something from /usr/*. So they want this beast be > mounted, before udev starts doing it's job. > > > Not arguing with *you* here Michael, just wondering about the > > validity of the position you quoted > > Understood :) > > Regards, > Michael > > -- Alan McKinnnon alan.mckin...@gmail.com
