Re: 'Machine ID' underspecified?

"Thomas Kluyver" <[email protected]>
Newsgroups gmane.comp.freedesktop.dbus
Message-ID <[email protected]>
On Mon, 7 Dec 2020, at 12:33, Simon McVittie wrote:
> Yes. The spec does say explicitly that "any attempt to reimplement D-Bus
> will probably require looking at the reference implementation and/or
> asking questions on the D-Bus mailing list about intended behavior".

Aha, I had overlooked that. I've been able to implement most of the basics just based on the spec and playing around with it interactively (I think I had one previous question about serial numbers). This question arose in Filipe's dbus-objects project, which builds higher level server features on top of my code.

> Some non-reference implementations such as systemd's sd-bus unconditionally
> use /etc/machine-id, or use /etc/machine-id in preference to
> /var/lib/dbus/machine-id. I would say that best-practice for "freedesktop"
> OS vendors is that /etc/machine-id and /var/lib/dbus/machine-id should both
> exist with the same contents, perhaps by making one a symlink to the other;
> and D-Bus implementations should read one of those files with a fallback to
> the other.
> 
> /etc/machine-id is a generalization of the D-Bus machine ID for non-D-Bus
> uses. It originated in systemd (see systemd's machine-id(5),
> <https://www.freedesktop.org/software/systemd/man/machine-id.html>) but
> I would encourage non-systemd-based "freedesktop" OS distributions like
> Devuan and *BSD to provide it too.
> 
> With hindsight, the reference implementation's use of a ${prefix}-relative
> path for the machine ID is unwise: if you don't know ahead of time where
> dbus was installed, it makes interoperability impossible. More generally,
> a package that installs in a GNU-style configurable ${prefix} isn't really
> compatible with providing a "filesystem API". However, in practice dbus is
> nearly always an OS component installed into /usr, /var and /etc, so
> assuming /var/lib/dbus/machine-id is nearly always correct.
> 
> systemd and dbus will both try to populate both /etc/machine-id and
> /var/lib/dbus/machine-id with the same content, although if the two IDs
> already exist with different content, at least dbus (probably systemd too)
> will leave both intact.

Thanks. So I think that can be summarised as: D-Bus implementations on Unix should try to read the machine ID from /var/lib/dbus/machine-id and /etc/machine-id (see also systemd machine-id). If both exist, they are expected to have the same contents, and if they differ, the spec does not define which takes precedence (the reference implementation prefers /var/lib/dbus/machine-id, but sd-bus does not).

If we wrote the /var/lib path in the spec, configuring the reference implementation to look in a different prefix would strictly make it non-spec-compliant, albeit in a way that would rarely matter (it will copy /etc/machine-id by default). Is that acceptable?

> I think the reformatting is essentially just removal of punctuation:
> Windows GUID {12340001-4980-1920-6788-123456789012} becomes D-Bus machine
> ID 12340001498019206788123456789012.

Got it :-)

> > Should this be described in the spec?
> 
> Sure, why not. Please send a merge request.

Great, will do!

> D-Bus over TCP has no integrity or confidentiality protection and has led to
> a 1.4 million vehicle recall[1] (presumably rather expensive)

Ouch, that must have been a bad day at Chrysler!

Thomas
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.