hal: remove block.block_size

[David Zeuthen]

On Sun, 2004-03-28 at 19:51, Robert Love wrote:
> > Therefore, we really need to have read permission to the device file and
> > that's why hald runs as root per default (there is some code for running
> > as a dedicated user but I believe this is commented out atm). Now,
> > setting and maintaining these permissions involves policy decisions and
> > is thus distribution specific and thus outside the scope of hal. 
> 
> Actually, I do not have any problem with HAL running as root if we need
> it to.  Maybe we should make the decision: root or non-root?
> 
> Root means:
> 
> 	- if we add callouts, they can run as root, which is very
> 	  needed
> 	- hal can do things like open device files, etc. to get all of
> 	  the information it needs
> 
> Non-root means:
> 
> 	- potentially more secure, cleaner?
> 

Well, yeah, hald does expose an interface (through the local system
message bus) and is as such a target for exploits. Especially with all
the manual marshalling and demarshalling going on since we don't use any
bindings yet. 

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.

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

I mean, hal won't specify the callouts (and will probably ship with
none) since per definition if something is implemented as a callout it's
a policy-dependent issue.. and callouts may run as setuid or use other
facilities (selinux) to get sufficient privileges. [1]

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.

Don't know..

Cheers,
David

[1] : and callouts still need to be implemented :-)