[PATCH] More lenient D-Bus policy

Zeeshan Ali Khattak zeeshanak
Sun May 25 03:41:46 PDT 2014

On Sun, May 25, 2014 at 11:29 AM, Johannes Berg
<johannes at sipsolutions.net> wrote:
> On Sun, 2014-05-25 at 11:10 +0100, Zeeshan Ali (Khattak) wrote:
>> > Introspect seems fine, but signals and properties might contain private
>> > data like wifi keys?
>> Thats a fair point. I see that the following interfaces don't have any
>> private data so I'll provide a v2 of this patch with only granting
>> access to them:
>> fi.w1.wpa_supplicant1
>> fi.w1.wpa_supplicant1.Interface
> I don't think that's true for .Interface - I believe you can retrieve
> blobs which may contain private keys.

Which properties or signals are those exactly?

> It would also stand to reason that to avoid breaking this in the future
> something should be done in the *code* to mark things as safe for
> anyone.

Yeah. you can easily deny access from code if/when you need to. We do
this sort of thing in Geoclue, where each client gets its own client
object and we reject any access to it by anyone other than the related
client. We also don't broadcast signals from these objects but send it
only to related client.

> Does DBus provide any mechanism where you could tag properties
> in some way and enable permissions based on that, or would it require
> another interface?

Unfortunately not and that is why I think you want to not restrict
access to properties through D-Bus policy but rather from code.


Zeeshan Ali (Khattak)
Befriend GNOME: http://www.gnome.org/friends/

More information about the Hostap mailing list