On 9/28/05, Claudio Takahasi <cktakahasi@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 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.

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 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 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 <marcel@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 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
>
> <======= Device ======>
> 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.

> <======= Manager ======>
> 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