Re: [gentoo-user] udev + /usr

[Paul Colquhoun]

On Mon, 12 Sep 2011 05:59:29 PM Michael Schreckenbauer wrote:
> Hi Canek,
>
> On Monday, 12. September 2011 11:35:13 Canek Peláez Valdés wrote:
> > (This would be my only post in this new thread: I think I have made my
> > point of view clear in the other thread).
> >
> > I have seen a lot of disinformation going on in the other threads
> > (like some people suggesting that /var would not be able to be on its
> > own partition at some point in the future). Just before everyone start
> > to wildy conjecture, please take a look at this:
> >
> > http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>
> well, the culprit here is:
> "The binaries called from these rules are sometimes located on /usr/bin, or
> link against libraries in /usr/lib, or use data files from /usr/share. If
> these rules fail udev will proceed with the next one, however later on
> applications will then not properly detect these udev devices or features
> of these devices."


My major worry is that udev is happily running arbitrary scripts from 
arbitrary locations early in the boot process, and is actively trying to make 
this easier.

How much more Microsoft-security-ish do we want Linux to get?

From a paranoid-security point of view, I think the proper solution is to just 
*insist* that all scripts/executables run from udev be located in /{s}bin * 
/lib  (or even in /udev_libexec) and run all scripts from a restricted shell 
to stop them just redirecting to somplace less secure.

Does udev even check to see if the scripts/executables are owned by root (a 
plus) or world writable (a big minus)?

I hope it doesn't take a Linux virus/worm using udev as a vector to prompt a 
review.

 
> Why doesn't udev queue failing scripts for later execution? It just assumes
> everything is in place in the moment it needs it. This is bad design for a
> tool, coming in so early in the boot process.
>
> > Also, a look at this thread is maybe justified:
> > http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/
>
> Same thing here. This all basically reads "We did some really bad design
> choices, now let's fix the surroundings."
> The following sentence really made me laugh:
>
> "> If so, what does LSB say to this new directory?
>
> Nothing really, they just document current common practice. We might
> request an update to LSB after it is used for a while and has shown
> that it is what we want."
>
> He does not know, if the thing he designed is the thing he wants.
> That's ridiculous!
>
> > Change happens.
>
> We already know this.
>
> > Regards everyone.
>
> Best,
> Michael
-- 
Reverend Paul Colquhoun, ULC.    http://andor.dropbear.id.au/~paulcol
 Before you criticize someone, you should walk a mile in their shoes.
Then, when you do, you'll be a mile away, and you'll have their shoes.