Return-Path: Message-ID: <3013cac80509281253332728c3@mail.gmail.com> From: Eduardo Rocha To: bluez-devel@lists.sourceforge.net Subject: Re: [Bluez-devel] hcid D-Bus patch In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1059_4109889.1127937188380" References: <1127398647.5344.24.camel@blade> <1127411650.12287.15.camel@blade> <1127644396.6362.6.camel@localhost.localdomain> <1127897100.5321.13.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: Wed, 28 Sep 2005 16:53:08 -0300 ------=_Part_1059_4109889.1127937188380 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Claudio, I'm new to the bluez world, but I'd like to make some questions. I've seen in your last email that you are suggesting that "everyone" will be able to call methods from Manager interface. Are you planning to make the Manager interface provide only query style methods or will every one able to change configurations (e.g pan configuration). Br, Eduardo. On 9/28/05, Claudio Takahasi wrote: > > Hi Marcel, > > 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. > > 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 t= o > 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. > > Another subject is the logical function names. If you want support > multiple adapters, it's necessary export one new path for each adapter. A= n > adapter identification must belongs to the object path. My suggestion is = use > hci(default kernel device), hci0, hci1, ... We can suggest a more suitabl= e > message member name, like you suggested for DeviceList, but for the objec= t > path I don't see an easiest way. > > 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 > > * 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) > > interface: "org.bluez.manager" (signals and request) can be shared for al= l > > manager services and signals. > comment: Available only when there is a device UP. The daemon must monito= r > DEV_UP/DEV_DOWN events and register/unregister the path dynamically. Each > service will be accessible through the default path and the device depend= ent > path. > > Regards, > Claudio. > > > On 9/28/05, Marcel Holtmann wrote: > > > > Hi Claudio, > > > > > Define clear object paths and interfaces will make easier define rule= s > > > in the D-Bus configuration file. In this file it's possible specify > > > the permissions for send and receive messages based on the interfaces= , > > > > > paths and users/groups. > > > > > > Based on your comment I suggested the paths and interfaces. Defining > > > this structure it's possible allow only the "root" or a "bluez > > > manager" user/group change the adapter settings. > > > > > > > > > SERVICE BUS NAME: org.bluez > > > > > > <=3D=3D=3D=3D=3D=3D=3D Device =3D=3D=3D=3D=3D=3D> > > > description: device specific configuration services. eg: (#1)display > > > local devices, inqmode, inqtype, up, down, reset, auth, noauth, > > > encrypt, ... > > > > > > object path: /org/bluez/Device > > > interface: /org/bluez/Device > > > > this looks good to me. > > > > > <=3D=3D=3D=3D=3D=3D=3D Manager =3D=3D=3D=3D=3D=3D> > > > description: connection services. eg: inquiry, remote name, info, > > > master/slave role switch, active connecions and profile specific > > > tasks. > > > Multiple local adapters scenario will be considered. The default > > > object path and the adapter specific paths will provide the same > > > services. > > > > > > /***** HCI ******/ > > > default object path:/org/bluez/Manager/hci (will use the default > > > device in the kernel) > > > object path: /org/bluez/Manager/hci0/hci > > > object path: /org/bluez/Manager/hci1/hci > > > interface: org.bluez.Manager.hci > > > > > > /***** SDP ******/ > > > default object path:/org/bluez/Manager/sdp > > > object path: /org/bluez/Manager/hci0/sdp > > > object path: /org/bluez/Manager/hci1/sdp > > > interface: org.bluez.Manager.sdp > > > > > > /***** PAN ******/ > > > default object path:/org/bluez/Manager/pan > > > object path: /org/bluez/Manager/hci0/pan > > > object path: /org/bluez/Manager/hci1/pan > > > interface: org.bluez.Manager.pan > > > > > > /***** RFCOMM ******/ > > > default object path:/org/bluez/Manager/rfcomm > > > object path: /org/bluez/Manager/hci0/rfcomm > > > object path: /org/bluez/Manager/hci1/rfcomm > > > interface: org.bluez.Manager.rfcomm > > > > Actually my plan is to don't use names like hci, sdp, rfcomm etc. at > > all. We should define logical function names. The user of the D-Bus API > > shouldn't need any Bluetooth protocol knowledge at all. So the idea > > would be call it discovery, network etc. > > > > > (#1) Probably the display local devices should be moved to other path > > > due the permissions that I comment before. User applications should > > > be able list the local adapters to use in the pan, rfcomm, sdp ... > > > > We maybe make Manager.DeviceList accessable by everybody. Are such > > things possible? > > > > > For me, your suggestion or my last suggestion are fine, both can > > > address the permissions. You have the decision in your hands! :) > > > > I like to have feedback and serious comments about, because I am still > > in the process to open my mind for D-Bus. > > > > 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 > Instituto Nokia de Tecnologia - INdT > claudio.takahasi@indt.org.br > ------=_Part_1059_4109889.1127937188380 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Claudio,

I'm new to the bluez world, but I'd like to make  some questions. I've seen in your last email that you are suggesting  that  "everyone" will be able to call methods from Manager interface. A= re you planning to make the Manager interface provide only query style methods or will every one able to change configurations (e.g pan configuration).

Br,
Eduardo.


On 9/28/05, Claudio Takahasi <ck= takahasi@gmail.com> wrote:
Hi Marcel,

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.

In my opinion, only a "bluez_admin" group should be able to use t= he service under the "/org/bluez/Devices" path. These services are r= elated to device configuration(hciconfig). Application that don't have enough
privileges will receive the error message: org.freedesktop.DBus.Error.Acces= sDenied

The other ordinary services under "org/bluez/Manager..." can be a= vailable 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.

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.

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

* 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 serv= ices)
 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 servi= ces)
 path: "/org/bluez/manager/hci0/serial" (RFCOMM services)  path: "/org/bluez/manager/hci1/serial" (RFCOMM services)  path: "/org/bluez/manager/hci/services" (default SDP publis= h/search)
 path: "/org/bluez/manager/hci0/services" (services SDP publ= ish/search)
 path: "/org/bluez/manager/hci1/services" (services SDP publ= ish/search)

 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.

Regards,
Claudio.



On 9/28/05, Marcel Holtmann <marc= el@holtmann.org > wrote:
Hi Claudio,

> Define clear object paths and interfaces will make = easier define rules
> in the D-Bus configuration file. In this file i= t's possible specify
> the permissions for send and receive messages = based on the interfaces,
> paths and users/groups.
>
> Based on your comment I su= ggested the paths and interfaces. Defining
> this structure it's poss= ible allow only the "root" or a "bluez
> manager"= user/group change the adapter settings.
>
>
> SERVICE BUS NAME: org.bluez
>
> <= =3D=3D=3D=3D=3D=3D=3D Device =3D=3D=3D=3D=3D=3D>
> description: de= vice specific configuration services. eg: (#1)display
> local devices= , inqmode, inqtype, up, down, reset, auth, noauth,
> encrypt, ...
>
> object path: /org/bluez/Device
>= ; interface: /org/bluez/Device

this looks good to me.

> &l= t;=3D=3D=3D=3D=3D=3D=3D Manager =3D=3D=3D=3D=3D=3D>
> description:= connection services. eg: inquiry, remote name, info,
> master/slave role switch, active connecions and profile specific> tasks.
> Multiple local adapters scenario will be considered. = The default
> object path and the adapter specific paths will provide= the same
> services.
>
> /***** HCI ******/
> default objec= t path:/org/bluez/Manager/hci (will use the default
> device in the k= ernel)
> object path: /org/bluez/Manager/hci0/hci
> object path= : /org/bluez/Manager/hci1/hci
> interface: org.bluez.Manager.hci
>
> /***** SDP ******= /
> default object path:/org/bluez/Manager/sdp
> object path: /= org/bluez/Manager/hci0/sdp
> object path: /org/bluez/Manager/hci1/sdp
> interface: org.bluez.Manager.sdp
>
> /***** PAN ******= /
> default object path:/org/bluez/Manager/pan
> object path: /= org/bluez/Manager/hci0/pan
> object path: /org/bluez/Manager/hci1/pan
> interface: org.bluez.Manager.pan
>
> /***** RFCOMM ***= ***/
> default object path:/org/bluez/Manager/rfcomm
> object p= ath: /org/bluez/Manager/hci0/rfcomm
> object path: /org/bluez/Manager= /hci1/rfcomm
> interface: org.bluez.Manager.rfcomm

Actually my plan is to = don't use names like hci, sdp, rfcomm etc. at
all. We should define logi= cal function names. The user of the D-Bus API
shouldn't need any Bluetoo= th protocol knowledge at all. So the idea
would be call it discovery, network etc.

> (#1) Probably the = display local devices should be moved to other path
> due the permiss= ions that I comment before. User  applications should
> be = able list the local adapters to use in the pan, rfcomm, sdp ...

We maybe make Manager.DeviceList accessable by everybody. Are such<= br>things possible?

> For me, your suggestion or my last suggesti= on are fine, both can
> address the permissions. You have the decisio= n in your hands! :)

I like to have feedback and serious comments about, because I am st= ill
in the process to open my mind for D-Bus.

Regards

Marc= el




-----------------------------------------------------= --
This SF.Net email is sponsored by:
Power Architecture Resource Cente= r: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mail= ing list
Bluez-deve= l@lists.sourceforge.net

--
--= -------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
claudio.takahasi@indt.o= rg.br

------=_Part_1059_4109889.1127937188380-- ------------------------------------------------------- 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