Return-Path: Message-ID: From: Claudio Takahasi To: bluez-devel@lists.sourceforge.net Subject: Re: [Bluez-devel] hcid D-Bus patch In-Reply-To: <1128069460.4955.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5451_23632457.1128091938444" References: <1127644396.6362.6.camel@localhost.localdomain> <1127897100.5321.13.camel@localhost.localdomain> <1128011132.30743.8.camel@localhost.localdomain> <1128069460.4955.25.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: Fri, 30 Sep 2005 11:52:18 -0300 ------=_Part_5451_23632457.1128091938444 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcel, We CAN'T use the full string representation of the bluetooth address. According with D-Bus specification the path name is restricted to "[A-Z][a-z][0-9]_". The character ":" is not allowed. See the rules: "* The path may be of any length. * The path must begin with an ASCII '/' (integer 47) character, and must consist of elements separated by slash characters. * Each element must only contain the ASCII characters "[A-Z][a-z][0-9]_" * No element may be the empty string. * Multiple '/' characters cannot occur in sequence. * A trailing '/' character is not allowed unless the path is the root path (a single '/' character)." Which approach do you want now ? :) More inforamtion how D-Bus paths works: This is just to explain to you how DBus paths works and try pass an useful information. If we analize HAL API deeply you will notice a small difference, HAL provide a Manager interface used to recover the devices(including paths) information. The Device interface is used by clients that want change/get ONE DEVICE property. Interfaces: org.freedesktop.Hal.Manager org.freedesktop.Hal.Device Manager interface services: - GetAllDevices - DeviceExists - FindDeviceByCapability .... Device interface services: - GetProperty - SetProperty - Lock - Unlock ... Path example: /org/freedesktop/Hal/devices/usb_device_a12_1_noserial_if0 (iface org.freedesktop.Hal.Device) One path represents a unique identification to where a message is sent. In the code that I am developing there is only one D-Bus message handler, the path will be the primary element to know which local adapter use. Remember that each path will provide a set of services, and each path can has more than one interface. We are using the path "/org/bluez/Manager" to provide to userspace application services to list ACTIVE devices and enable/disable services. Th= e path "/org/bluez/Devices" will be restricted to device setup. Therefore, th= e message format used in "/org/bluez/Devices" path should contains one arguments to indicate the device identification, like hciconfig uses. For the messages send under the path "/org/bluez/Manager/BDADDR/..." is not necessary send this argument because the path already contains the device identification. The prefix "/org/bluez/Manager" used before device based path is not realy necessary. It is used only to make easier find services under this hierarchy. HAL DOESN'T provide an extra path as we are doing for device setup "/org/bluez/Devices" all paths are device based. If you want copy exactly HAL paths principle, we should have: /org/bluez/Manager /org/bluez/Devices/BDADDR/Hciconfig (always active) /org/bluez/Devices/BDADDR/Hciconfig (always active) /org/bluez/Devices/BDADDR/Controller (if dev is UP) /org/bluez/Devices/default/Controller (if dev is UP) /org/bluez/Devices/BDADDR/Net (if dev is UP) /org/bluez/Devices/default/Net (if dev is UP) And use two interfaces: org.bluez.Manager org.bluez.Devices I will send a new patch in the next email. Regards, Claudio. On 9/30/05, Marcel Holtmann wrote: > > Hi Claudio, > > > 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. > > this might be true, because I am a total newbie when it comes to D-Bus > security. I have to rely on other peoples investigation here. > > > 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. > > This means we will have a generell restricted policy and we create some > holes to make specific calls available for normal users. > > > 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 will go with "default", because at some point I might make the HCI > device identifier strings changeable, like we can do for Ethernet. The > BDADDR_ANY is not needed, but we can do this. However this means that I > have to implement a possibility to define a default device inside the > kernel. Otherwise BDADDR_ANY in D-Bus and inside the kernel might end up > in two different devices. For the address representation I will use the > string representation "00:11:22:33:44:55", because this is how normal > users will see the address and there is no need to obfuscate the address > for it. > > > 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 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 > > device identification belongs to the path. > > > > After this analysis I think we are following the right path. > > I think so, too. Please send in a new patch. We need something to get > started and as you, I like it step by step. > > 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_5451_23632457.1128091938444 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcel,

We CAN'T use the full string representation of the bluetooth address. According with D-Bus specification the path name is restricted to "[A-Z][a-z][0-9]_".  The character ":" is not allo= wed. See the rules:
    "* The path may be of any length.
    * The path must begin with an ASCII '/' (integer 47) character, and must consist of elements separated by slash characters.
    * Each element must only contain the ASCII characters &q= uot;[A-Z][a-z][0-9]_"
    * No element may be the empty string.
    * Multiple '/' characters cannot occur in sequence.
    * A trailing '/' character is not allowed unless the pat= h is the root path (a single '/' character)."


Which approach do you want now ? :)




More inforamtion how D-Bus paths works:
This is just to explain to you how DBus paths works and try pass an useful information. If we analize HAL API deeply you will notice a small difference, HAL provide a Manager interface used to recover the devices(including paths) information. The Device interface is used by clients that want change/get ONE DEVICE property.

Interfaces:
org.freedesktop.Hal.Manager
org.freedesktop.Hal.Device

Manager interface services:
- GetAllDevices
- DeviceExists
- FindDeviceByCapability
....

Device interface services:
- GetProperty
- SetProperty
- Lock
- Unlock
...

Path example:
/org/freedesktop/Hal/devices/usb_device_a12_1_noserial_if0 (iface org.freed= esktop.Hal.Device)

One path represents a unique identification to where a message is sent. In the code that I am developing there is only one D-Bus message handler, the path will be the primary element to know which local adapter use. Remember that each path will provide a set of services, and each path can has more than one interface.

We are using the path "/org/bluez/Manager" to provide to userspac= e application services to list ACTIVE devices and enable/disable services. The path "/org/bluez/Devices" will be restricted to dev= ice setup. Therefore, the message format used in "/org/bluez/Devices"= path should contains one arguments to indicate the device identification, like hciconfig uses. For the messages send under the path "/org/bluez/Manager/BDADDR/..." is not necessary send this argume= nt because the path already contains the device identification.

The prefix "/org/bluez/Manager" used before device based path is = not realy necessary. It is used only to make easier find services under this hierarchy.

HAL DOESN'T provide an extra path as we are doing for device setup "/org/bluez/Devices" all paths are device based. If you want copy exactly HAL paths principle, we should have:
/org/bluez/Manager
/org/bluez/Devices/BDADDR/Hciconfig (always active)
/org/bluez/Devices/BDADDR/Hciconfig (always active)
/org/bluez/Devices/BDADDR/Controller (if dev is UP)
/org/bluez/Devices/default/Controller (if dev is UP)
/org/bluez/Devices/BDADDR/Net (if dev is UP)
/org/bluez/Devices/default/Net (if dev is UP)

And use two interfaces:
org.bluez.Manager
org.bluez.Devices



I will send a new patch in the next email.

Regards,
Claudio.


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

> I don't want define a group domain for evey group o= f access. I think
> you didn't understand my idea. I defined fixed in= terfaces
> (org.bluez.manager or org.bluez.devices) and path names ba= sed on
> device identification.

this might be true, because I am a t= otal newbie when it comes to D-Bus
security. I have to rely on other peo= ples investigation here.

> In the security policy file we can def= ine rules according with our
> need.  We can define rules based on paths, interfaces, u= sers,
> group ... or a combination of these parameters. At first phas= e of
> bluetoothd development we need only define clear interfaces an= d path
> to make possible define security policy easily in the future. We d= on't
> need thinking on define a group domain or rules at this mommen= t.
>
> The interfaces name will be shared by method call, metho= d reply,
> errors and signals. Remember that one path, can have a lot of
&= gt; interfaces.  Interfaces is just a way to group a set of
&g= t; methods(services). Therefore, if you apply one rule for a path, this
= > rule will be applied for all interfaces that belongs to this path.

This means we will have a generell restricted policy and we create = some
holes to make specific calls available for normal users.

>= ; 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 b= luetooth
> 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", &= quot;E4A500461300" The final
> decision is yours.

I will = go with "default", because at some point I might make the HCI
device identifier strings changeable, like we can do for Ethernet. The<= br>BDADDR_ANY is not needed, but we can do this. However this means that I<= br>have to implement a possibility to define a default device inside the
kernel. Otherwise BDADDR_ANY in D-Bus and inside the kernel might end u= p
in two different devices. For the address representation I will use th= e
string representation "00:11:22:33:44:55", because this is h= ow normal
users will see the address and there is no need to obfuscate the addres= s
for it.

> I checked the libhal code, a similar approach is i= mplemented. 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 las= t one is the member name(service). "udi" means unique device
> identification.
>
> LIBHAL side(client):
>
>&n= bsp;        message =3D dbus_message_new= _method_call ("org.freedesktop.Hal",
> udi,
>
>= "org.freedesktop.Hal.Device",
>           &= nbsp;           &nbs= p;            &= nbsp;            "GetAllProperties");
>      &= nbsp;  message =3D dbus_message_new_method_call ("org.freedesktop= .Hal",
>
> "/org/freedesktop/Hal/Manager",
&g= t;
> "org.freedesktop.Hal.Manager ",
>          =             &nb= sp;            =             &nb= sp; "GetAllDevices");
>      &nbs= p;  message =3D dbus_message_new_method_call ("org.freedesktop.Ha= l",
> udi,
>
> "org.freedesktop.Hal.Device"= ;,
>           = ;            &n= bsp;            = ;             "GetPropertyType");
>      &n= bsp;  message =3D dbus_message_new_method_call ("org.freedesktop.= Hal",
> udi,
>
> "org.freedesktop.Hal.Device&qu= ot;,
>
> "GetPropertyStringList");
>         message =3D dbus_m= essage_new_method_call ("org.freedesktop.Hal",
> udi,
&g= t;
> "org.freedesktop.Hal.Device",
>   = ;            &n= bsp;            = ;            &n= bsp;        "GetPropertyInteger");
>      = ;   message =3D dbus_message_new_method_call ("org.freedeskt= op.Hal",
> udi,
>
> "org.freedesktop.Hal.Device= ",
>          =             &nb= sp;            =             &nb= sp; "GetPropertyInteger");
>      = ;   message =3D dbus_message_new_method_call ("org.freedeskt= op.Hal",
> udi,
>
> "org.freedesktop.Hal.Device= ",
>          =             &nb= sp;            =             &nb= sp; "GetPropertyDouble");
> In the server side - hald(daemon)> DBusHandlerResult
> device_get_property (DBusConnection * conn= ection, DBusMessage *
> message){
> ...
> udi =3D dbus_me= ssage_get_path (message);
> ..
> }
>
> Basically, HAL has two interfaces, on= e for devices and another for the
> manager. Each device has path reg= istered in the system Bus, where the
> device identification belongs = to the path.
>
> After this analysis I think we are following the right pat= h.

I think so, too. Please send in a new patch. We need something to= get
started and as you, I like it step by step.

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_5451_23632457.1128091938444-- ------------------------------------------------------- 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