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: > > <allow send_interface="org.bluez.Agent" send_path="/org/bluez/Agent"/> > > 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 <allow send_interface>, but ideally we > don't have many of these since they're not as strong as <allow > 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
