Live data from Hacker News

Devuan considers machine IDs

distrowatch.com

1–10 of 76 posts

Re: Devuan considers machine IDs

#2
If a file on your computer is being used by a program to send information to someone, the answer isn't to destroy/randomize the file and break other applications, the answer is to not use the program that is sending your information somewhere.

Re: Devuan considers machine IDs

#4

If a file on your computer is being used by a program to send information to someone, the answer isn't to destroy/randomize the file and break other applications, the answer is to not use the program that is sending your information somewhere.

Sure, but how do you know what programs are misusing it?

Re: Devuan considers machine IDs

#5
post #3

Why is it there in the first place?

https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html has some explanation, in particular:

> The important properties of the machine UUID are that 1) it remains unchanged until the next reboot and 2) it is different for any two running instances of the OS kernel. That is, if two processes see the same UUID, they should also see the same shared memory, UNIX domain sockets, local X displays, localhost.localdomain resolution, process IDs, and so forth.

Because it's possible to forward things like D-Bus, the X11 $DISPLAY, etc. over the network, two processes might be aware of each other over such a connection but not be running on the same machine and therefore be unable to share resources. The machine ID lets them check for that, so you can properly handle things like "I'm going to send a message to the screensaver in my display to not activate, I don't care if it's the same machine" vs. "I'm going to send a message to the terminal in my display to open a new tab, but only if it's actually on the same machine, otherwise I should start a new terminal". (These days I think that definition should be updated to "container" instead of "kernel": if you're running separate logical machines inside the same kernel with separate PIDs etc., they should have separate machine IDs.)

systemd and (IIRC) cloud-init use it to run once-per-machine tasks on machines that could come from images: if you want to prep a number of machines in advance, do the install, then change the machine ID. At boot time, startup scripts will say "Oh, this machine ID has not been initialized yet" and do things, and then not do them on the next boot.

Re: Devuan considers machine IDs

#7
OK, from the man page:

> The /etc/machine-id file contains the unique machine ID of the local system that is set during installation. The machine ID is a single newline-terminated, hexadecimal, 32-character, lowercase ID. When decoded from hexadecimal, this corresponds to a 16-byte/128-bit value.

> The machine ID is usually generated from a random source during system installation and stays constant for all subsequent boots. Optionally, for stateless systems, it is generated during runtime at early boot if it is found to be empty.

So if that works for "stateless systems", why can't all machines be "stateless systems"?

Re: Devuan considers machine IDs

#8

If a file on your computer is being used by a program to send information to someone, the answer isn't to destroy/randomize the file and break other applications, the answer is to not use the program that is sending your information somewhere.

Or sandbox the program so that it sees a "safe" version of that information.

Re: Devuan considers machine IDs

#10
post #4

If a file on your computer is being used by a program to send information to someone, the answer isn't to destroy/randomize the file and break other applications, the answer is to not use the program that is sending your information somewhere.

Sure, but how do you know what programs are misusing it?

This speaks to a more general need for user-friendly audit logs of which resources are accessed by which programs. I should be able to tell on any platform if Spotify called fopen on something in my documents folder.
Post reply on HN