On Thu, Sep 8, 2011 at 4:05 PM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > 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. > > 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)? > > 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?
It is a matter of what else do you end having in /bin and /lib. Remember that udev rules can execute arbitrary code. Do all that code needs to be moved to /bin and /lib also? I keep telling: it is a difficult problem. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
