[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xdg
Subject:    Re: hal: remove block.block_size
From:       Robert Love <rml () ximian ! com>
Date:       2004-03-28 21:10:22
Message-ID: 1080508222.4941.40.camel () localhost
[Download RAW message or body]

On Sun, 2004-03-28 at 13:08, David Zeuthen wrote:

> Now, dbus itself is pretty anal about what it let's through (I've been
> thrown off the bus at several occasions when composing invalid messages
> during development), but it's still a potential vulnerability if there
> is a buffer overflow bug in hald.

Yah, I am not too concerned about the security issues - just mentioning
both sides. ;)

> Maybe this running as non-root / root is a policy decision as well? E.g.
> something left for distributors to decide?

Well, as far as e.g. for callouts and such, sure.  But we should make a
decision about whether HAL requires root, for privileged execution.  For
example, say some mechanism (like the MII registers we use now [I know
they are going away - just an example]) requires root.  We should either
say "we cannot use those, HAL is not required to be root" or "HAL can
use those, HAL runs as root."  In other words, we should decide if HAL
is root or non-root and codify that into what HAL can or cannot do.

> So, the only requirement so far is access to the device files and one
> can configure udev to set permissions correctly, so it should be
> straightforward to get hal to run as non-root.

But we cannot make the entire hard drive read-able by the world.  So we
would have to make the device node read-able by a group, and make HAL a
member of that group.  And do this for any device node that HAL needs to
access.

Which is fine and do-able.  But then I would say, just make HAL run as
root and be done with it :)

	Robert Love




[prev in list] [next in list] [prev in thread] [next in thread]