hal: remove block.block_size
rml at ximian.com
Mon Mar 29 00:10:22 EEST 2004
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
Which is fine and do-able. But then I would say, just make HAL run as
root and be done with it :)
More information about the xdg