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

[Eduardo Rocha <folhabranca@gmail.com>]

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

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

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