FROMLIST: Properly set owner of filter data at start of client creation
Currently at the start of client creation (g_dbus_client_new), the
|owner| in |filter_data| is not set until the |name| is resolved. This
creates a time window where the filter doesn't work properly, i.e. it
filters in more than it should. To solve this issue, this patch does the
following:
1. At the start of client creation, set the |owner| in |filter_data|
based on the current resolved |name| if any, or set it explicitly to
unknown (empty string) as opposed to NULL otherwise. The unknown |owner|
lets the filter reject any message, unlike NULL |owner| which accepts
any message.
2. Step 1 above reveals another bug: message_filter fails to accept
messages which have |sender| set directly to D-Bus service name rather
than D-Bus address. Therefore this patch relaxes the filter requirement
in message_filter to accept a message if its |sender| is equal directly
to our filter's |name|.
3. After the initial service name resolution (after GetNameOwner)
returns, immediately update our name cache with the result, otherwise
the filters' |owner| would be stuck to unknown (empty string) until
"NameOwnerChanged" signal arrives.
4. However, not all service will call GetNameOwner, therefore we relax
the condition by always calling it when a service is added.
Upstream: https://marc.info/?l=linux-bluetooth&m=156843556024385
BUG=chromium:1002784, chromium:1019443
TEST=Verify with these steps:
A) To verify chromium:1002784
1) Make sure bluetoothd and btdispatch is running, newblued is not.
start bluetoothd
start btdispatch
stop newblued
2) Trigger initialization of adapter.
rmmod btusb
modprobe btusb
3) Confirm that newblue_proxy_added is never wrongly triggered
anymore.
B) To verify chromium:1019443
1) Pair to a device.
2) send this DBus message (update the device address accordingly).
dbus-send --system --type=method_call --print-reply \
--dest=org.chromium.Bluetooth \
/org/bluez/hci0/dev_C8_4C_04_6B_1C_6B \
org.chromium.BluetoothDevice.GetConnInfo
3) Verify that there would be a successful reply in this format:
method return time=1572557061.987567 sender=:1.90 -> \
destination=:1.118 serial=411 reply_serial=2
int16 -35
int16 8
int16 8
Change-Id: Ic0981042296e04d47549188e8fa49267976a6293
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/bluez/+/1893557
Reviewed-by: Yoni Shavit <[email protected]>
Tested-by: Archie Pusaka <[email protected]>
Commit-Queue: Archie Pusaka <[email protected]>
1 file changed
