Re: [RFE] Support signaling only connections owned by specific uid

Hey

On Thu, 8 Apr 2021 at 13:57, Pavel Březina <[email protected]> wrote:
>
> On 4/8/21 11:22 AM, David Rheinsberg wrote:
> > Hi
> >
> > On Thu, 8 Apr 2021 at 11:12, Bogdan Lotko <[email protected]> wrote:
> >> I don't know the details, but is it not much more simple to make a
> >> broadcast and process the message only in applications that belong to
> >> specified user?
> >
> > To extend on that, a simple solution is to only broadcast public
> > information and require callers to request more data via a
> > method-call. This method-call can then be guarded by uid verification,
> > etc. The D-Bus `PropertiesChanged` signal allows for a simple solution
> > by utilizing the `invalidated-properties` feature, rather than
> > including payload directly in the signal.
>
> This is not possible. The signal itself is private information, so it
> needs to be delivered only to the user processes.

If the mere fact that the signal _happened_ is already private
information, this might indeed not be suitable. In all other cases,
this is IMO a neat way to get this behavior _now_.

> > On a different note, you can always send directed-signals as unicasts
> > to all interested/authorized parties. These will not be proper
> > multicasts, though, thus subject to re-ordering.
>
> Yes, as I wrote in the description, there are solutions to workaround
> lack of this functionality. However, it all requires lots of additional
> work to manage subscribed parties and it also requires sending a single
> message to each subscriber which may become a bottleneck if sssd-kcm
> notifications are overused.

Speaking about `dbus-broker`, the algorithmic complexity remains
`O(n)` with `n` being the number of receivers. I think this is true
for dbus-daemon as well, so I don't think you need to worry about
performance bottlenecks.

> Therefore we want to pursue this RFE in dbus if possible. Notifications
> are signals, so the proper implementation should be based on signals. We
> just need to limit the broadcast a little bit.

FYI: Broadcasts and signals are not synonymous in D-Bus, even though
they are often treated as such. Unicast-messages can be signals just
like broadcasts can be. So my suggested workaround would still use
"dbus signals". However, I do get your point that this seems rather
convoluted.

Regarding your proposed extension: I think it lacks justification.
Yes, you might have a single use-case, but there are workarounds.
Furthermore, if you wanted a `uid` destination, where do we stop? Do
we just support any destination-selector that might be needed? What
about `gid`? What about `selinux-label`? (I am not trying to ridicule
the idea, just trying to see its effects from the
broker-implementation side)

I think the broadcast system was always intended as public information
(but smcv can probably tell you a lot more about it, or correct me
here). The fact that bus-policies limit this is more of a
mandatory-access-check rather than a programmatic interface. You can
see this in the message header, which allows you to deduce the
destination of a message just based on D-Bus peer names. No
destination means broadcast, explicit destination means unicast to
_that peer_. Adding another field `destination_uid=<uid>` would break
with this and make it hard to debug where a message goes.

In the past, I argued in favor of `destination=<array-of-peers>`
allowing for proper multicasts in D-Bus. This would possibly play into
your hand: You would still have to manage the list of receivers, but
at least the message transmission would be a proper multicast, rather
than a series of unicasts. This would then avoid hard-coding the
`uid=` feature in dbus, and allow any kind of selector as a
client-side feature.
Anyway, the multicast discussion never got to an implementation, so
maybe this is just moot.

David
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus