DBus: not reading /etc/machine-id breaks DBus GetMachineId

[nephros]

Steps to reproduce:

1. have a QML application all set up, using Nemo.DBusAdapter to create an Interface (f. ex. service org.example.MyApp, path /org/example/MyApp, iface org.example.MyApp), and necessary settings in .desktop
2. launch the application (Exec=sailfish-qml harbour-myapp)
3. test that the interface is available, e.g. busctl --user introspect org.example.MyApp /org/example/MyApp
4. observe that the default methods Ping and GetMachineId are listed under name org.freedesktop.DBus.Peer
5. Try to call busctl --user call org.example.MyApp org.example.MyApp org.freedesktop.DBus.Peer GetMachineId
6. get an error message back (see below)

D-Bus library appears to be incorrectly set up: see the manual page for dbus-uuidgen to correct this issue. (Failed to open "/var/lib/dbus/machine-id": No such file or directory; Failed to open "/etc/machine-id": No such file or directory)

/etc/machine-id is available and set up correctly outside the box.

I suggest to add the following around here:

diff -u a/Base.permission b/Base.permission
--- a/Base.permission   2024-06-13 08:27:33.921509080 +0200
+++ b/Base.permission   2024-06-13 08:27:52.913610640 +0200
@@ -65,6 +65,7 @@
 private-etc dconf
 private-etc passwd,group
 private-etc os-release
+private-etc machine-id
 # private-etc content for symlinks is not copied, see
 # https://github.com/netblue30/firejail/issues/2966
 private-etc sailfish-release

unless there are concerns about privacy or security about /etc/machine-id.

I realize that this is probably not a critical interface, however maybe in inspecting this other issues regarding FDO expectations are found.

[spiiroin]

Interestingly it seems that (outside sanbox) you can ask machine id from any other dbus service but dbus daemon itself - I wonder if the method / whole peer interface has been blocked on purpose and what that purpose might be?

Anyway, regarding sailjail: Is there some rationale for hiding machine-id file? @Tomin1 @rainemak Any thoughts?

[nephros]

Interestingly it seems that (outside sanbox) you can ask machine id from any other dbus service but dbus daemon itself - I wonder if the method / whole peer interface has been blocked on purpose and what that purpose might be?

They are world-readable in general.

ls -l /var/lib/dbus/machine-id /etc/machine-id
-rw-r--r--    1 root     root            33 Sep 30  2022 /etc/machine-id
-rw-r--r--    1 root     root            33 Oct 23  2021 /var/lib/dbus/machine-id

Of course the very privacy-conscious may argue that access to something that allows to uniquely identify the device a user is running on is something that needs to be prevented.

Sailfish OS may opt to declare itself "stateless" for this case (man machine-id)

The machine ID is usually generated from a random source during system installation or first boot and stays constant for all subsequent boots. Optionally, for stateless systems, it is generated during runtime during early boot if necessary.

... but that is a design decision for systemd (and has consequences for its behaviour).

[LaakkonenJussi]

Of course the very privacy-conscious may argue that access to something that allows to uniquely identify the device a user is running on is something that needs to be prevented.

Sailfish OS may opt to declare itself "stateless" for this case (man machine-id)

This might be the best idea here. To use stateless machine-id and to allow it to be read like proposed here. This way tracking based on machine-id would be reasonably well obfuscated by changing it at every boot.