Bug 93755 - tell monitors what clients' credentials are
Summary: tell monitors what clients' credentials are
Status: RESOLVED MOVED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: git master
Hardware: Other All
: medium enhancement
Assignee: D-Bus Maintainers
QA Contact: D-Bus Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-18 11:18 UTC by Simon McVittie
Modified: 2018-10-12 21:26 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon McVittie 2016-01-18 11:18:46 UTC
On the system bus, particularly when using LSMs, it's useful for monitors to be able to see the credentials of D-Bus connections.

It's also useful for monitors to be able to "catch up" with the details of who owns which names.

dbus-daemon could follow this logic:

on a new connection {
    inject a Monitoring.ConnectionInfo signal into all monitors
}

when a connection becomes a monitor {
    for each existing connection {
        inject a Monitoring.ConnectionInfo signal into that monitor, as if the
        connection had just connected
    }
}

where Monitoring.ConnectionInfo is something like this:

    o.fd.DBus.Monitoring.ConnectionInfo(s, s, as, a{sv})
        s: unique_name
        s: debug_string
            a human-readable, not necessarily trustworthy representation
            of the connection
            (implementation: this is basically
            BusConnectionData->cached_loginfo_string)
        as: well_known_names
        a{sv}: same things returned by GetConnectionCredentials

dbus-monitor could either display these by default, or have a command-line option to display them.

For efficiency, ConnectionInfo should not actually be sent on the real bus, just sent to monitors.
Comment 1 Simon McVittie 2016-02-08 14:01:24 UTC
Bustle also wants to know what names exist, and who owns them. bustle-pcap does this in a race-prone way by calling ListNames() and GetNameOwner(), but it would be nicer if BecomeMonitor could just tell the monitor up-front.

I saw far enough ahead when I added BecomeMonitor to give it a flags argument, so maybe we should have a flag BECOME_MONITOR_FLAG_ANNOUNCE_NAMES which would make dbus-monitor synthesize NameOwnerChanged messages and stuff them into the new monitor socket on startup, and a similar flag for this?
Comment 2 GitLab Migration User 2018-10-12 21:26:11 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/140.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.