Hi Marcel,<br>
<br>
I don't want define a group domain for evey group of access. I think
you didn't understand my idea. I defined fixed interfaces
(org.bluez.manager or org.bluez.devices) and path names based on device
identification. <br>
<br>
In the security policy file we can define rules according with our
need.&nbsp; We can define rules based on paths, interfaces, users,
group ... or a combination of these parameters. At first phase of
bluetoothd development we need only define clear interfaces and path to
make possible define security policy easily in the future. We don't
need thinking on define a group domain or rules at this momment.<br>
<br>
The interfaces name will be shared by method call, method reply, errors
and signals. Remember that one path, can have a lot of
interfaces.&nbsp; Interfaces is just a way to group a set of
methods(services). Therefore, if you apply one rule for a path, this
rule will be applied for all interfaces that belongs to this path.<br>
<br>
Regarding the device identification in the path name, I prefer use
hci(for default kernel device), hci1, hci2, ... It's easier use the
device id of &quot;evt_si_device&quot; event. You suggested use the bluetooth
address, for this approach we can define a the default
device(000000000000), and use the string&nbsp; representation of
bdaddr_t for the others devices. eg:&quot;A089BE880D00&quot;, &quot;E4A500461300&quot; The
final decision is yours.<br>
<br>
I checked the libhal code, a similar approach is implemented. See how
the messages are created. The first argument of the
dbus_message_new_method_call function is the service bus name, the
second is the path, the third is the interface and <br>
the last one is the member name(service). &quot;udi&quot; means unique device identification.<br>
<br>
LIBHAL side(client):<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message = dbus_message_new_method_call (&quot;org.freedesktop.Hal&quot;, udi,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;org.freedesktop.Hal.Device&quot;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;GetAllProperties&quot;);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message = dbus_message_new_method_call (&quot;org.freedesktop.Hal&quot;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;/org/freedesktop/Hal/Manager&quot;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;org.freedesktop.Hal.Manager&quot;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;GetAllDevices&quot;);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message = dbus_message_new_method_call (&quot;org.freedesktop.Hal&quot;, udi,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;org.freedesktop.Hal.Device&quot;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;GetPropertyType&quot;);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message = dbus_message_new_method_call (&quot;org.freedesktop.Hal&quot;, udi,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;org.freedesktop.Hal.Device&quot;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;GetPropertyStringList&quot;);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message = dbus_message_new_method_call (&quot;org.freedesktop.Hal&quot;, udi,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;org.freedesktop.Hal.Device&quot;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;GetPropertyInteger&quot;);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message = dbus_message_new_method_call (&quot;org.freedesktop.Hal&quot;, udi,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;org.freedesktop.Hal.Device&quot;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;GetPropertyInteger&quot;);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message = dbus_message_new_method_call (&quot;org.freedesktop.Hal&quot;, udi,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;org.freedesktop.Hal.Device&quot;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;GetPropertyDouble&quot;);<br>
In the server side - hald(daemon)<br>
DBusHandlerResult<br>
device_get_property (DBusConnection * connection, DBusMessage * message){<br>
...<br>
udi = dbus_message_get_path (message);<br>
..<br>
}<br>
<br>
Basically, HAL has two interfaces, one for devices and another for the
manager. Each device has path registered in the system Bus, where the
device identification belongs to the path.<br>
<br>
After this analysis I think we are following the right path.<br>
<br>
Regards,<br>
Claudio.<br><br><div><span class="gmail_quote">On 9/29/05, <b class="gmail_sendername">Marcel Holtmann</b> &lt;<a href="mailto:marcel@holtmann.org">marcel@holtmann.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Claudio,<br><br>&gt; Regarding the DeviceList permission, It possible define rules for<br>&gt; allow/deny services based on interface name, path, user, groups,<br>&gt; message type, service name(member name), ...<br>&gt;
<br>&gt; Therefore, provide just one interface or path is not a good idea<br>&gt; because we will not be able to create permission rules and a clean<br>&gt; API.<br><br>my hope is to make the permission of the BlueZ D-Bus API more flexible
<br>and thus having a separate group &quot;domain&quot; for every group of access<br>sounds totally stupid to me. The permissions shouldn't have to do<br>anything with the logical structure of the API.<br><br>People with more D-Bus experience than me please comment on it.
<br><br>&gt; In my opinion, only a &quot;bluez_admin&quot; group should be able to use the<br>&gt; service under the &quot;/org/bluez/Devices&quot; path. These services are<br>&gt; related to device configuration(hciconfig). Application that don't
<br>&gt; have enough<br>&gt; privileges will receive the error message:<br>&gt; org.freedesktop.DBus.Error.AccessDenied<br>&gt;<br>&gt; The other ordinary services under &quot;org/bluez/Manager...&quot; can be<br>&gt; available for everyone.
<br>&gt;<br>&gt; Currently we are not providing any kind of session control. All<br>&gt; userspace applications will be able to control connections and<br>&gt; interfere in a connection used by other application.<br><br>Maybe we should restrict this somehow, but I have no clue on how to do
<br>it at the moment. I am fully open to proposals.<br><br>&gt; Another subject is the logical function names. If you want support<br>&gt; multiple adapters, it's necessary export one new path for each<br>&gt; adapter. An adapter identification must belongs to the object path. My
<br>&gt; suggestion is use hci(default kernel device), hci0, hci1, ... We can<br>&gt; suggest a more suitable message member name, like you suggested for<br>&gt; DeviceList, but for the object path I don't see an easiest way.
<br><br>We can always use the BD_ADDR instead and maybe also an alias that can<br>be set by bluetoothd/hcid.<br><br>&gt; See below how I have want organize the service after your suggestions.<br>&gt;<br>&gt; &gt;&gt;&gt; Device PATH
<br>&gt; permission: only bluez_admin group<br>&gt; path: /org/bluez/device<br>&gt; interface: org.bluez.device<br>&gt;<br>&gt; &gt;&gt;&gt; Manager PATH<br>&gt; permission: everyone<br>&gt; path: /org/bluez/Manager<br>&gt; interface: 
org.bluez.manager<br><br>I think these are clear and they look good, but we should look at other<br>D-Bus services how they design their API.<br><br>&gt; * Device Independent Service<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager&quot;
<br>&gt;&nbsp;&nbsp;interface: &quot;org.bluez.manager&quot; (signals and request)<br>&gt;&nbsp;&nbsp;comment: Always active<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;1. Init (version check)<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;2. DeviceList<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;3. ListServices (list available services)<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;4. Enable (Enable an service. eg: all pan related services)<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;5. Disable<br>&gt;<br>&gt; * Device dependent Service<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci/controller&quot; (default HCI services)<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci0/controller&quot; (HCI services)
<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci1/controller&quot; (HCI services)<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci/pan&quot; (default PAN services)<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci0/pan&quot; (PAN services)
<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci1/pan&quot; (PAN services)<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci/serial&quot; (default RFCOMM services)<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci0/serial&quot; (RFCOMM services)
<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci1/serial&quot; (RFCOMM services)<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci/services&quot; (default SDP publish/search)<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci0/services&quot; (services SDP
<br>&gt; publish/search)<br>&gt;&nbsp;&nbsp;path: &quot;/org/bluez/manager/hci1/services&quot; (services SDP<br>&gt; publish/search)<br><br>I like to use the word &quot;default&quot; to select the default device/service<br>and &quot;network&quot; instead of &quot;pan&quot;, because PAN is the way to go. The
<br>fallback to LAP is optional.<br><br>&gt;&nbsp;&nbsp;interface: &quot;org.bluez.manager&quot; (signals and request) can be shared<br>&gt; for all<br>&gt;&nbsp;&nbsp;manager services and signals.<br>&gt;&nbsp;&nbsp;comment: Available only when there is a device UP. The daemon must
<br>&gt; monitor&nbsp;&nbsp;DEV_UP/DEV_DOWN events and register/unregister the path<br>&gt; dynamically. Each&nbsp;&nbsp;service will be accessible through the default path<br>&gt; and the device&nbsp;&nbsp;dependent path.<br><br>Please check how HAL is handling the device register and unregister. I
<br>think their current interface is quite good.<br><br>Regards<br><br>Marcel<br><br><br><br><br>-------------------------------------------------------<br>This SF.Net email is sponsored by:<br>Power Architecture Resource Center: Free content, downloads, discussions,
<br>and more. <a href="http://solutions.newsforge.com/ibmarch.tmpl">http://solutions.newsforge.com/ibmarch.tmpl</a><br>_______________________________________________<br>Bluez-devel mailing list<br><a href="mailto:Bluez-devel@lists.sourceforge.net">
Bluez-devel@lists.sourceforge.net</a><br><a href="https://lists.sourceforge.net/lists/listinfo/bluez-devel">https://lists.sourceforge.net/lists/listinfo/bluez-devel</a><br></blockquote></div><br><br clear="all"><br>-- <br>
---------------------------------------------------------<br>Claudio Takahasi<br>Nokia's Institute of Technology - INdT<br><a href="mailto:claudio.takahasi@indt.org.br">claudio.takahasi@indt.org.br</a><br>