How to ensure DBUS is broken (in clusters and bus-connected NUMA machines)

[Linda A. Walsh]

Simon McVittie wrote:
> On 02/10/15 01:47, Linda A. Walsh wrote:
>   
>> re: #4 -- imagine a compute engine that requires expensive authentication
>> and/or link encryption over a cluster internal bus  -- it would be
>> a design killer.
>>     
>
> If this is "a single machine" in the sense that it runs one kernel, then
> D-Bus should be using AF_UNIX sockets, as it does by default on all Unix
> platforms. Those are basically memory being copied between processes, so
> they might not be optimally fast in a NUMA architecture, but that's the
> price you pay for having a more complicated memory architecture.
>   
So the recent notes about a Dbus service for screenshots and performance
metrics are both a bit out of place?  D-Bus is for low-speed signalling?
>  Uses of D-Bus include notification of system changes (notification of
> when a camera is plugged in to a computer, or a new version of some
> software has been installed), or desktop interoperability, for example a
> file monitoring service or a configuration service.
>
>  D-Bus is designed for two specific use cases:
>
> * A "system bus" for notifications from the system to user sessions, and
> to allow the system to request input from user sessions.
>
> * A "session bus" used to implement desktop environments such as GNOME
> and KDE
>   
---  
    A session bus doesn't imply same machine -- one can have devices
plugged into a diskless workstation or X-display that expect to get
information from a compute engine.  Both Nvidia and Intel sell 100+ cpu
"peripherals" that can do a mix of computing and display, but neither would
be "the same computer" running "the same OS".  Yet what devices are
plugged in and communicating are essential in a session.

    Why would one have nodes with senders like "org.freedesktop.Dbus" when
there is to be no contact outside of a given computer?  Snapshots
aren't I/O from a user -- but from autonomous daemons.  Several dbus
related services have their own daemon's to talk autonomously apart from
User I/O. 

    I.e. the current implementation already has connection points outside
of the roles you list above. 

    As it stands now, I can create a desktop session w/dbus running on
my desktop, that is unable to talk to my compute and disk devices --
again -- already I'm seeing dbus not being able to attach to various
devices -- while at the same time I see discussion of implementing it for
image (multi-image? heading toward remote desktop usage?) and others
questioning about ways to measure performance and efficiency.

    SSH didn't start with the intention of being a protocol underlying
remote disks or VPN, but it is still being used for that.  It seems short
sited not to think of allowing for _both_ untrusted and trusted foreign
connections as needed for some individual application.

    One of the ssh implementations uses encryption for authorization, but
reverts to clear-text for bulk sessions after that.

>
> D-Bus is designed to be a "signalling" protocol, not a "bulk data"
> protocol: messages should travel when something "interesting" happens,
> not continuously. If your use-case involves a continuous stream of data
> between nodes, there are plenty of other options.
>   
----
    Seems to be broken by design.  If I get a message of a camera
plugged in or audio, or a high-speed disk being attached & mounted -- then
I have to go somewhere else to actually make use of those devices? 
That would be like using 'ssh' to login, but requiring the users to
use some other protocol like ftp, rsync, or remote command execution.

At the same time you seem to be saying that DBUS should be prevented
from being used for 1 session spread over several compute and storage
devices over a closed (private /separate from public) net.  That
seems unnecessarily short-sited.