Re: [Bluez-devel] bluetoothd D-Bus interface proposals(draft 00.05)

[Claudio Takahasi <cktakahasi@gmail.com>]

Hi folks,


After this long discussion I think control multiple apdaters
will not be easy. If we register multiple paths will not be easy=20
map device register/unregister to D-Bus paths. When the user=20
remove the default dongle the D-Bus path should be unregistered and=20
the default adapter should be changed.=20

Considering that bluez daemons are using the BDADDR_ANY. The D-Bus=20
services should use the same approach. I agree that the default=20
adapter must go through the kernel.

Is there a way/interface to change the default adapter in the kernel?=20

Regarding security issues. The bluetoothd will run with root right.
The security policy shall be controlled by D-Bus configuration
files. It's possible add rule based on method names and interfaces.

Regards,
Claudio.

On 8/22/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Paul,
>=20
> > Another big concern I'm having is about security, most hciconfig
> > commands require 'higher than normal' privileges to execute, should
> > the daemon allow certain requests only to the root user ? (luckily
> > dbus was conceived with security in mind, so adding such a policy
> > would not be difficult).
> > This would just make things more complicated and I don't think there's
> > any real gain in doing so, but maybe there are some security issues I
> > ignore at the moment, let me know your opinion.
> > (if for example, a program calls ListDevices to list the adapters, and
> > the user wants to use an interface which is not active, should the
> > program be allowed to bring it up?)
>=20
> the bluetoothd run with root (or chroot) rights and thus it needs to
> provide its own security policy.
>=20
> > What if two (or more) applications chose, for whatever reason, to set
> > a different default adapter? If you *really* want such a mechanism,
> > maybe you should make such a method callable only by authorized code
> > (hence my dilemma above) or simply select the default adapter
> > internally in the daemon and don't expose this method at all.
>=20
> as I said in the previous answers, the setting which is the default
> adapter must go through the kernel.
>=20
> Regards
>=20
> Marcel
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel