BlueZ configuration file/security question

Claudio Takahasi cktakahasi at
Thu Nov 30 11:01:35 PST 2006


I guess everybody knows BlueZ is now providing a D-Bus Interface.
Currently, we are trying design an easy way to provide service
registration. Basically, if one application wants provide a Bluetooth
service it must register the service in the "hcid daemon". Messages
must not be  sent directly to the ServiceAgent, the clients must send
the messages through the hcid, who will forward the message to the

Only the hcid has a well-known name("org.bluez"), when a ServiceAgent
registers a new service, the service path is provided. This parameter
is used to register a object path in the hcid, therefore service
CLIENTS must set the destination to "org.bluez" and the path to the
service path provided in the registration procedure.

We know that there is an overhead when forwarding messages, but it is
a cost of the design and the idea is not send a lot of messages.

[Client]-------[hcid] -----> [ServiceAgent]

* Client: any application that wants use BlueZ services.

* hcid: main BlueZ daemon that manages local adapter setup tasks,
remote device discover, authetication, ...

* ServiceAgent: applications that wants provide a Bluetooth service.
eg: Audio, Network, Input, etc. ServiceAgents don't have a well-known

How we can AVOID send message directly to the ServiceAgent? (it is
possible send a message directly to the ServiceAgent using the "unique
connection name" and the right path)

The first option is let the ServiceAgents check if the sender is the
hcid, but we don't let the ServiceAgents developers implement this
verification. Maybe the hcid could handle this(inside the daemon or
using the policy file)

Maybe this link can help you understand how it works:

I understand that it is not a big flaw, because the "unique connection
name" is required to send the message directly. But it is nice if we
block this scenario.

Claudio Takahasi
Instituto Nokia de Tecnologia - INdT

More information about the dbus mailing list