[RFE] Support signaling only connections owned by specific uid

[Pavel Březina]

On 4/8/21 4:35 PM, David Rheinsberg wrote:
> Hey
> 
> On Thu, 8 Apr 2021 at 13:57, Pavel Březina <pbrezina at redhat.com> wrote:
>>
>> On 4/8/21 11:22 AM, David Rheinsberg wrote:
>>> Hi
>>>
>>> On Thu, 8 Apr 2021 at 11:12, Bogdan Lotko <bogdan at lotko.at> 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.

Just because a workaround exist (and non-trivial one), it should not be 
seen as it lacks justification. What I am describing is a valid use case 
that would extend possibilities of daemons.

> 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)

Where do we stop? Why should we stop? D-Bus is used heavily nowadays and 
the development should not stop. It should definitely continue adding 
new features to gain more traction.

You can already translate D-Bus name into uid so this information is 
already available. I'm not sure about gid and selabels. If this RFE is 
accepted, it would be good to design it so it can be extended by other 
stuff but not implementing other options unless requested.

> 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.

Harder, not impossible.

> 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.

Managing the list of receivers is a possibility, but not something we 
are interested in since sssd-kcm is a short-lived process and therefore 
we can't just listed to NameOwnerChanged (and similar) signals. We would 
have to find other tools that requires more I/O which we want to avoid. 
In general, we won't use dbus for this unless this feature is implemented.

Thanks,
Pavel

> 
> David
>