Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
Hi Colin, > > that is exactly how it works and we can't use signal. Even directed > > signal are not working since the method call into the agent has to > > return the result or an error. > > > > What problem do you guys actually have with this? The agent inside > > bluez-gnome is verifying that the method comes from the daemon it > > registers its agent with and thus there is not even a security issue > > here with trying to send arbitrary method calls to the UI. > > I talked with davidz about this on IRC in a bit more high bandwidth > mode; he's doing something similar with PolicyKit. I think if the > rule is of the form: > > > > that's probably fine. It does allow any process to send any message > with that interface and path to any other, but we're in a similar > situation with signals anyways right now. I wouldn't call it a > problem even if it's just an , but ideally we > don't have many of these since they're not as strong as send_destination>. the path where the Bluetooth agent lives can be freely chosen by the agent. We are not restricting it to any path. This is needed since in some cases an application might wanna register two agents. The BlueZ agents are kinda stackable. We have a default one for normal requests that can come in any time. And then transaction specific ones when we do expect a pairing or authorization request. This design is on purpose to allow the UI to present or overwrite these requests and handle them as it fits best in that situation. So what is your security concern here? Only the root user is to send these information anyway. And once you are root, you can do whatever you want. If you don't like the D-Bus policy, you just edit that file and change it. I really don't get what you are trying to protect here. And keep in mind that the client/agent has to protect itself and bluez-gnome is doing this by verifying the sender of the request. Regards Marcel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
Hi Colin, > > As far as I can tell, BlueZ agents work like this: > > > > * the agent (a UI process run by a user) calls a method on the hci daemon > > (run > > by root) and passes in its unique name and its (arbitrary) object path > > * later, the hci daemon calls a method on the agent > > > > so the only thing that can be relied on is that when the hci daemon calls > > the method, it's on the org.bluez.Agent interface! > > Urf. Can we just change this to use signals? Signals can be sent to > a particular destination only (I'm pretty sure). that is exactly how it works and we can't use signal. Even directed signal are not working since the method call into the agent has to return the result or an error. What problem do you guys actually have with this? The agent inside bluez-gnome is verifying that the method comes from the daemon it registers its agent with and thus there is not even a security issue here with trying to send arbitrary method calls to the UI. Regards Marcel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#392156: [Pkg-bluetooth-maintainers] Bug#392156: FTBFS: has no member named 'link_sup_to'
Hi Martin, > Package: bluez-hcidump > Version: 1.31-1 > Severity: serious > > This package fails to build in unstable: > > > Automatic build of bluez-hcidump_1.31-1 on coconut0 by sbuild/ia64 0.49 > ... > > cc -DHAVE_CONFIG_H -I. -I. -I.. -g -Wall -O2 -D_FORTIFY_SOURCE=2 -c > > lmp.c > > cc -DHAVE_CONFIG_H -I. -I. -I.. -g -Wall -O2 -D_FORTIFY_SOURCE=2 -c > > hci.c > > hci.c: In function 'write_link_supervision_timeout_dump': > > hci.c:964: error: 'write_link_supervision_timeout_cp' has no member named > > 'link_sup_to' > > hci.c: In function 'read_link_supervision_timeout_dump': > > hci.c:1489: error: 'read_link_supervision_timeout_rp' has no member named > > 'link_sup_to' > > make[3]: *** [hci.o] Error 1 > > make[3]: Leaving directory `/build/tbm/bluez-hcidump-1.31/parser' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory `/build/tbm/bluez-hcidump-1.31' an update to bluez-hcidump-1.32 is needed. Got fixed upstream. Regards Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378839: [Pkg-bluetooth-maintainers] Bug#378839: bluez-pcmcia-support: udev support broken
Hi,
> > > PHYSDEVPATH and the 'device' link are both deprecated and will go away
> > > some day in the future, you better pass the values you want to use in
> > > your script down from udev with $sysfs{}. That is not dependent on a
> > > specific order of devices in sysfs.
>
> > I've attached working (for me) rules+bluetooth.sh. $sysfs{manf_id} and
> > $sysfs{card_id} are passed to bluetooth.sh.
>
> Looks fine, and should not break, if something in sysfs changes, which
> is nice.
>
> Btw, you should be able to just do RUN+="bluetooth.sh", as udev will
> look in /lib/udev/ if it does not start with a '/'.
this is nice, but there is no need to run bluetooth.sh on non-serial
based Bluetooth cards like the Nokia DTL1 for example. They work
perfectly fine without any additional udev rule.
I also don't like that bluetooth.sh tries to run /etc/init.d/bluetooth,
because this should not be a task of an udev script. Either Bluetooth is
enabled to be started a system boot or not.
The other thing is that this is not Debian specific. So why does nobody
tried to start an upstream discussion on bluez-devel or linux-hotplug
mailing list.
Regards
Marcel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
