Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi <cktakahasi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6599 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 8004 bytes --]