On Mar 4, 2023, at 06:32, Tijl Coosemans <t...@freebsd.org> wrote: > > On Fri, 3 Mar 2023 10:36:20 -0800 Mark Millard <mark...@yahoo.com> wrote: >> What are the properties for the content of /etc/hostid >> in FreeBSD? Where are they documented? >> >> /etc/machine-id has strong property guarnatee >> requirements in linux and dbus (which linux indicates >> it has adopted requirements from): >> >> https://man7.org/linux/man-pages/man5/machine-id.5.html >> >> reports: >> >> QUOTE >> The machine ID does not change based on local or network >> configuration or when hardware is replaced. Due to this and its >> greater length, it is a more useful replacement for the >> gethostid(3) call that POSIX specifies. >> >> This machine ID adheres to the same format and logic as the D-Bus >> machine ID. >> END QUOTE > > /etc/hostid is written once. It does not change with network or > hardware changes. > >> https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html reports: >> ( used via dbus-uuidgen --ensure=/etc/machine-id as one way >> to get a linux-comaptibile /etc/machine-id for at least >> some types of contexts ) >> >> QUOTE >> 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 >> END QUOTE >> >> >> Does /etc/hostid generated the normal way in FreeBSD have such >> properties? (How do I look that up?) > > Yes. It's `kenv smbios.system.uuid` if that's available and generated > by uuidgen otherwise. The code is in /etc/rc.d/hostid and > /etc/rc.d/hostid_save.
I probably also should have quoted the below for completeness: QUOTE Also, don't make it the same on two different systems; it needs to be different anytime there are two different kernels running. END QUOTE There are implications for some virtual environments. >> Returning to: >> >> https://man7.org/linux/man-pages/man5/machine-id.5.html >> >> QUOTE >> This ID uniquely identifies the host. It should be considered >> "confidential", and must not be exposed in untrusted >> environments, in particular on the network. If a stable unique >> identifier that is tied to the machine is needed for some >> application, the machine ID or any part of it must not be used >> directly. Instead the machine ID should be hashed with a >> cryptographic, keyed hash function, using a fixed, >> application-specific key. That way the ID will be properly >> unique, and derived in a constant way from the machine ID but >> there will be no way to retrieve the original machine ID from the >> application-specific one. >> END QUOTE >> >> Is that at least recommended for handling FreeBSD's /etc/hostid >> content? > > No, the file is not documented at all, but this is a recommendation on > how to use the file not a restriction on the content like the other > quotes so this isn't an impediment to using the same ID in > /etc/machine-id. That presumes that what FreeBSD does with /etc/hostid content keeps the content confidential by default, such as using hashing to avoid there being a way to "retrieve the original machine ID". (It may well, but that is not documented.) Otherwise following the recommendation would be an impossibility for /etc/hostid content. >> Is FreeBSD going to document /etc/machine-id content properties >> in a similar manor? >> >> >> If FreeBSD ends up with a /etc/machine-id that does not have >> the properties and recommended principles of use, it would >> appear that the /etc/machine-id path would be highly misleading >> and, so, inappropriate. Thanks for the notes. === Mark Millard marklmi at yahoo.com
