Return-Path: Message-ID: From: Claudio Takahasi To: bluez-devel@lists.sourceforge.net Subject: Re: [Bluez-devel] hcid D-Bus patch In-Reply-To: <1128011132.30743.8.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_781_16321165.1128022007568" References: <1127411650.12287.15.camel@blade> <1127644396.6362.6.camel@localhost.localdomain> <1127897100.5321.13.camel@localhost.localdomain> <1128011132.30743.8.camel@localhost.localdomain> Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net Reply-To: bluez-devel@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ development List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Sep 2005 16:26:47 -0300 ------=_Part_781_16321165.1128022007568 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcel, 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. In the security policy file we can define rules according with our need. We can define rules based on paths, interfaces, users, group ... or a combination of these parameters. At first phase of bluetoothd development w= e 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 domai= n or rules at this momment. The interfaces name will be shared by method call, method reply, errors and signals. Remember that one path, can have a lot of interfaces. Interfaces i= s 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. 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 "evt_si_device" event. You suggested use the bluetooth address, for this approach we can define a the default device(000000000000), and use the string representation of bdaddr_t for the others devices. eg:"A089BE880D00"= , "E4A500461300" The final decision is yours. 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_cal= l function is the service bus name, the second is the path, the third is the interface and the last one is the member name(service). "udi" means unique device identification. LIBHAL side(client): message =3D dbus_message_new_method_call ("org.freedesktop.Hal", udi, "org.freedesktop.Hal.Device", "GetAllProperties"); message =3D dbus_message_new_method_call ("org.freedesktop.Hal", "/org/freedesktop/Hal/Manager", "org.freedesktop.Hal.Manager", "GetAllDevices"); message =3D dbus_message_new_method_call ("org.freedesktop.Hal", udi, "org.freedesktop.Hal.Device", "GetPropertyType"); message =3D dbus_message_new_method_call ("org.freedesktop.Hal", udi, "org.freedesktop.Hal.Device", "GetPropertyStringList"); message =3D dbus_message_new_method_call ("org.freedesktop.Hal", udi, "org.freedesktop.Hal.Device", "GetPropertyInteger"); message =3D dbus_message_new_method_call ("org.freedesktop.Hal", udi, "org.freedesktop.Hal.Device", "GetPropertyInteger"); message =3D dbus_message_new_method_call ("org.freedesktop.Hal", udi, "org.freedesktop.Hal.Device", "GetPropertyDouble"); In the server side - hald(daemon) DBusHandlerResult device_get_property (DBusConnection * connection, DBusMessage * message){ ... udi =3D dbus_message_get_path (message); .. } Basically, HAL has two interfaces, one for devices and another for the manager. Each device has path registered in the system Bus, where the devic= e identification belongs to the path. After this analysis I think we are following the right path. Regards, Claudio. On 9/29/05, Marcel Holtmann wrote: > > Hi Claudio, > > > Regarding the DeviceList permission, It possible define rules for > > allow/deny services based on interface name, path, user, groups, > > message type, service name(member name), ... > > > > Therefore, provide just one interface or path is not a good idea > > because we will not be able to create permission rules and a clean > > API. > > my hope is to make the permission of the BlueZ D-Bus API more flexible > and thus having a separate group "domain" for every group of access > sounds totally stupid to me. The permissions shouldn't have to do > anything with the logical structure of the API. > > People with more D-Bus experience than me please comment on it. > > > In my opinion, only a "bluez_admin" group should be able to use the > > service under the "/org/bluez/Devices" path. These services are > > related to device configuration(hciconfig). Application that don't > > have enough > > privileges will receive the error message: > > org.freedesktop.DBus.Error.AccessDenied > > > > The other ordinary services under "org/bluez/Manager..." can be > > available for everyone. > > > > Currently we are not providing any kind of session control. All > > userspace applications will be able to control connections and > > interfere in a connection used by other application. > > Maybe we should restrict this somehow, but I have no clue on how to do > it at the moment. I am fully open to proposals. > > > Another subject is the logical function names. If you want support > > multiple adapters, it's necessary export one new path for each > > adapter. An adapter identification must belongs to the object path. My > > suggestion is use hci(default kernel device), hci0, hci1, ... We can > > suggest a more suitable message member name, like you suggested for > > DeviceList, but for the object path I don't see an easiest way. > > We can always use the BD_ADDR instead and maybe also an alias that can > be set by bluetoothd/hcid. > > > See below how I have want organize the service after your suggestions. > > > > >>> Device PATH > > permission: only bluez_admin group > > path: /org/bluez/device > > interface: org.bluez.device > > > > >>> Manager PATH > > permission: everyone > > path: /org/bluez/Manager > > interface: org.bluez.manager > > I think these are clear and they look good, but we should look at other > D-Bus services how they design their API. > > > * Device Independent Service > > path: "/org/bluez/manager" > > interface: "org.bluez.manager" (signals and request) > > comment: Always active > > 1. Init (version check) > > 2. DeviceList > > 3. ListServices (list available services) > > 4. Enable (Enable an service. eg: all pan related services) > > 5. Disable > > > > * Device dependent Service > > path: "/org/bluez/manager/hci/controller" (default HCI services) > > path: "/org/bluez/manager/hci0/controller" (HCI services) > > path: "/org/bluez/manager/hci1/controller" (HCI services) > > path: "/org/bluez/manager/hci/pan" (default PAN services) > > path: "/org/bluez/manager/hci0/pan" (PAN services) > > path: "/org/bluez/manager/hci1/pan" (PAN services) > > path: "/org/bluez/manager/hci/serial" (default RFCOMM services) > > path: "/org/bluez/manager/hci0/serial" (RFCOMM services) > > path: "/org/bluez/manager/hci1/serial" (RFCOMM services) > > path: "/org/bluez/manager/hci/services" (default SDP publish/search) > > path: "/org/bluez/manager/hci0/services" (services SDP > > publish/search) > > path: "/org/bluez/manager/hci1/services" (services SDP > > publish/search) > > I like to use the word "default" to select the default device/service > and "network" instead of "pan", because PAN is the way to go. The > fallback to LAP is optional. > > > interface: "org.bluez.manager" (signals and request) can be shared > > for all > > manager services and signals. > > comment: Available only when there is a device UP. The daemon must > > monitor DEV_UP/DEV_DOWN events and register/unregister the path > > dynamically. Each service will be accessible through the default path > > and the device dependent path. > > Please check how HAL is handling the device register and unregister. I > think their current interface is quite good. > > Regards > > Marcel > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Bluez-devel mailing list > Bluez-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bluez-devel > -- --------------------------------------------------------- Claudio Takahasi Nokia's Institute of Technology - INdT claudio.takahasi@indt.org.br ------=_Part_781_16321165.1128022007568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcel,

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.

In the security policy file we can define rules according with our need.  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.

The interfaces name will be shared by method call, method reply, errors and signals. Remember that one path, can have a lot of interfaces.  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.

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 "evt_si_device" event. You suggested use the bluetoo= th address, for this approach we can define a the default device(000000000000), and use the string  representation of bdaddr_t for the others devices. eg:"A089BE880D00", "E4A5004= 61300" The final decision is yours.

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
the last one is the member name(service). "udi" means unique devi= ce identification.

LIBHAL side(client):

        message =3D dbus_message_new_met= hod_call ("org.freedesktop.Hal", udi,
            &nb= sp;            =             &nb= sp;          "org.freedesktop.Hal.Device",
            &nb= sp;            =             &nb= sp;          "GetAllProperties");
        message =3D dbus_message_new_met= hod_call ("org.freedesktop.Hal",
            &nb= sp;            =             &nb= sp;          "/org/freedesktop/Hal/Manager",
            &nb= sp;            =             &nb= sp;          "org.freedesktop.Hal.Manager",
            &nb= sp;            =             &nb= sp;          "GetAllDevices");
        message =3D dbus_message_new_met= hod_call ("org.freedesktop.Hal", udi,
            &nb= sp;            =             &nb= sp;          "org.freedesktop.Hal.Device",
            &nb= sp;            =             &nb= sp;          "GetPropertyType");
        message =3D dbus_message_new_met= hod_call ("org.freedesktop.Hal", udi,
            &nb= sp;            =             &nb= sp;          "org.freedesktop.Hal.Device",
            &nb= sp;            =             &nb= sp;          "GetPropertyStringList");
        message =3D dbus_message_new_met= hod_call ("org.freedesktop.Hal", udi,
            &nb= sp;            =             &nb= sp;          "org.freedesktop.Hal.Device",
            &nb= sp;            =             &nb= sp;          "GetPropertyInteger");
        message =3D dbus_message_new_met= hod_call ("org.freedesktop.Hal", udi,
            &nb= sp;            =             &nb= sp;          "org.freedesktop.Hal.Device",
            &nb= sp;            =             &nb= sp;          "GetPropertyInteger");
        message =3D dbus_message_new_met= hod_call ("org.freedesktop.Hal", udi,
            &nb= sp;            =             &nb= sp;          "org.freedesktop.Hal.Device",
            &nb= sp;            =             &nb= sp;          "GetPropertyDouble");
In the server side - hald(daemon)
DBusHandlerResult
device_get_property (DBusConnection * connection, DBusMessage * message){ ...
udi =3D dbus_message_get_path (message);
..
}

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.

After this analysis I think we are following the right path.

Regards,
Claudio.

On 9/29/05, Marcel Holtmann <marcel@holtmann.org> wrote:
Hi Claudio,

> Regarding the DeviceList permission, It possible de= fine rules for
> allow/deny services based on interface name, path, u= ser, groups,
> message type, service name(member name), ...
>
> Therefore, provide just one interface or path is not a good idea> because we will not be able to create permission rules and a clean> API.

my hope is to make the permission of the BlueZ D-Bus API= more flexible
and thus having a separate group "domain" for every group of = access
sounds totally stupid to me. The permissions shouldn't have to do=
anything with the logical structure of the API.

People with more= D-Bus experience than me please comment on it.

> In my opinion, only a "bluez_admin" group should be = able to use the
> service under the "/org/bluez/Devices" pa= th. These services are
> related to device configuration(hciconfig). = Application that don't
> have enough
> privileges will receive the error message:
= > org.freedesktop.DBus.Error.AccessDenied
>
> The other ordi= nary services under "org/bluez/Manager..." can be
> availab= le for everyone.
>
> Currently we are not providing any kind of session control= . All
> userspace applications will be able to control connections an= d
> interfere in a connection used by other application.

Maybe= we should restrict this somehow, but I have no clue on how to do
it at the moment. I am fully open to proposals.

> Another sub= ject is the logical function names. If you want support
> multiple ad= apters, it's necessary export one new path for each
> adapter. An ada= pter identification must belongs to the object path. My
> suggestion is use hci(default kernel device), hci0, hci1, ... We c= an
> suggest a more suitable message member name, like you suggested = for
> DeviceList, but for the object path I don't see an easiest way.

We can always use the BD_ADDR instead and maybe also an alias that = can
be set by bluetoothd/hcid.

> See below how I have want org= anize the service after your suggestions.
>
> >>> Devi= ce PATH
> permission: only bluez_admin group
> path: /org/bluez/device=
> interface: org.bluez.device
>
> >>> Manager P= ATH
> permission: everyone
> path: /org/bluez/Manager
> i= nterface:=20 org.bluez.manager

I think these are clear and they look good, but we= should look at other
D-Bus services how they design their API.

&= gt; * Device Independent Service
>  path: "/org/bluez/= manager"
>  interface: "org.bluez.manager" (signals and r= equest)
>  comment: Always active
>   =  1. Init (version check)
>    2. DeviceList<= br>>    3. ListServices (list available services) >    4. Enable (Enable an service. eg: all pan relat= ed services)
>    5. Disable
>
> * De= vice dependent Service
>  path: "/org/bluez/manager/hc= i/controller" (default HCI services)
>  path: "/o= rg/bluez/manager/hci0/controller" (HCI services)
>  path: "/org/bluez/manager/hci1/controller" (H= CI services)
>  path: "/org/bluez/manager/hci/pan"= ; (default PAN services)
>  path: "/org/bluez/manager/= hci0/pan" (PAN services)
>  path: "/org/bluez/manager/hci1/pan" (PAN serv= ices)
>  path: "/org/bluez/manager/hci/serial" (d= efault RFCOMM services)
>  path: "/org/bluez/manager/h= ci0/serial" (RFCOMM services)
>  path: "/org/bluez/manager/hci1/serial" (RFCOM= M services)
>  path: "/org/bluez/manager/hci/services&= quot; (default SDP publish/search)
>  path: "/org/blue= z/manager/hci0/services" (services SDP
> publish/search)
>  path: "/org/bluez/manager/= hci1/services" (services SDP
> publish/search)

I like to = use the word "default" to select the default device/service
an= d "network" instead of "pan", because PAN is the way to= go. The
fallback to LAP is optional.

>  interface: "or= g.bluez.manager" (signals and request) can be shared
> for all>  manager services and signals.
>  comment:= Available only when there is a device UP. The daemon must
> monitor  DEV_UP/DEV_DOWN events and register/unregister = the path
> dynamically. Each  service will be accessible th= rough the default path
> and the device  dependent path.
Please check how HAL is handling the device register and unregister. I
think their current interface is quite good.

Regards

Marc= el




-----------------------------------------------------= --
This SF.Net email is sponsored by:
Power Architecture Resource Cen= ter: Free content, downloads, discussions,
and more. http:= //solutions.newsforge.com/ibmarch.tmpl
_____________________________= __________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/list= info/bluez-devel



-- ---------------------------------------------------------
Claudio Takaha= si
Nokia's Institute of Technology - INdT
claudio.takahasi@indt.org.br
------=_Part_781_16321165.1128022007568-- ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel