HAL virtualization (was Re: dbus: api or implementation detail)

[David Zeuthen]

On Wed, 2005-07-13 at 14:01 -0700, Artem Kachitchkine wrote:
> > I think the direction we're moving towards is to some day deprecating
> > libhal in favor of programming languages / runtimes (glib, Qt,
> > Java, .NET/Mono) using D-BUS bindings to access HAL.
> 
> I see. Here's the reason I asked and was hoping that the HAL ABI is
> wrapped in an API.
> 
> I'm looking for the best way to run HAL in a virtual context as opposed
> to system-wide. Each virtual context is assigned a subset of all devices
> available to the system: it could be as simple as a subdir under /dev or
> a random mix of special device files; let's call it "devlist". A virtual
> context is uniquely identified by a token, an ascii string. Given a
> token, one can easily retrieve a devlist associated with it.

I see. Interesting.

> A desktop session running in a virtual context has the token set in an
> environment variable. The goal is to create an illusion that devlist is
> all there is: e.g. lshal and hal-device-manager would only show objects
> from devlist, g-v-m will only get signalled for volumes belonging to
> the block devices in devlist.
> 
> So if the hald patty was sandwiched between the backend bun from below
> and some kind of a library bun from above, that would allow me to
> encapsulate the virtualization logic into the buns.
> 
> The lower half is straightforward: for a hald process running in a
> virtual context, the backend would getenv() the token, retrieve the
> devlist and feed it into GDL.
> 
> The upper half has alternatives. The solution should meet two requirements:
> 
> R1. No application source code changes required.
> R2. D-BUS messages from different virtual contexts are isolated from
> each other. We can't let Alice see that Bob inserted a CD labeled
> 'naughty pix'.
> 
> I guess R2 excludes the scheme with passing the token along with
> org.freedesktop.Hal.Manager methods and signals.
> 
> I'm not very familiar with D-BUS, so please bear with me. I understand
> that I can run dbus-daemon --session and create a named bus, to be used
> by the desktop session's apps. The dbus spec says "libdbus automatically
> discovers the address of the per-session bus daemon by reading an
> environment variable" -the DBUS_SESSION_BUS_ADDRESS variable, which the
> apps have to set - which breaks R1, because all current applications use
> the system bus.

Right, the session and system buses are quite different and serve
totally different purposes. Btw, for HAL, the session bus isn't used at
all.

> If there was a library on top of hald, that library would do token ->
> DBUS_SESSION_BUS_ADDRESS mapping transparently, say in libhal_ctx_init().
> 
> Your thoughts would be greatly appreciated.
> 

Well, all access to hald is through the system bus (libhal is just a
convenience library) which allows you to get the uid of the connection
from clients [1]. So, basically, I would get the uid of the connection
(just ask the system bus, e.g. dbus_connection_get_unix_user()), lookup
the virtual context token (assuming a one-to-one correspondence between
udi and virtual context token) and filter inside hald for e.g.
GetAllDevices(). 

However, the downside is that this doesn't work with asynchronous
signals, e.g. the signal "CD-ROM disc with volume.label='naughty pix'
added" from hald would be broadcast to all clients, e.g. both Alice and
Bob. This would violate R2. In reality, however it's not this way: today
hald will only broadcast the signal DeviceAdded(object_path udi) and
clients will have to GetAllProperties(udi) to actually discover that
volume.label='naughty pix'... So, GetAllProperties will fail for
everyone but Bob (cause of the filtering mentioned above), so you only
need to make sure that existing software gracefully handles such errors
(which it should anyway but this is rarely/never tested). So I think
this satisfies both R1 and R2. 

So, to recap, the proposed solution is to basically to only filter all
methods in the hald process. This would solve everything I think, and
it's a pretty simple modification to hald. Would something like this
work? 

Of course, depending on how much virtualization (ranging from e.g.
chrooted jails to things like Xen and VMWare) you want to use there's
other options such as the obvious one of running separate copies of the
system bus and hald in each context [2]. 

Cheers,
David

[1] : as well as other metadata; e.g. on Linux you should be able to get
the SELinux security context the client app is running in. 

[2] : of course, running multiple copies of hald that both tries to poll
the same hardware may be problematic too. On e.g. VMWare this would all
be virtual hardware anyway :-)


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal