9 ms·

Devuan considers machine IDs

57 points by tomkat0789 8y ago

nickysielicki 8y ago
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.
- mirimir 8y ago
  Sure, but how do you know what programs are misusing it?
  - btown 8y ago
    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.
    - nickysielicki 8y ago
      I think this is largely possible with eBPF, if you cared enough.
    - auslander 8y ago
      SELinux or app-armor, keep it in enforcing mode.
  - jlgaddis 8y ago
    auditd(8)
    - mirimir 8y ago
      Thanks. https://security.blogoverflow.com/2013/01/a-brief-introduction-to-auditd/ https://security.blogoverflow.com/2013/01/a-brief-introducti...
  - yellowapple 8y ago
    Rename it and see which programs complain :)
- 0815test 8y ago
  Or sandbox the program so that it sees a "safe" version of that information.
- ez7r6i 8y ago
  Chromium reads it, but are we sure it's sending it somewhere? Maybe it uses it for bookkeeping of local sessions or something like that.
  - koolba 8y ago
    I checked the Chromium source and for Linux they explicitly mention not being allowed to send it externally[0]; they hash it via SHA1, encode it as base64, and use that value. Interestingly for Windows they pull the machine id from the registry[1] and (at first glance) it doesn't seem like they're doing any hashing. The raw value gets used. Haven't checked if the value gets sent externally but based upon the comment on the Linux code I'd bet it's a yes. [0]: https://github.com/chromium/chromium/blob/aae20fb7d3616de40e2af077bb02aaecb2b13d7f/chrome/browser/policy/browser_dm_token_storage_linux.cc#L89-L111 https://github.com/chromium/chromium/blob/aae20fb7d3616de40e... [1]: https://github.com/chromium/chromium/blob/01a03aab2d89c93c157c9af52dca7ac20d8ed96b/chrome/browser/policy/browser_dm_token_storage_win.cc#L129-L148 https://github.com/chromium/chromium/blob/01a03aab2d89c93c15...
    - jolmg 8y ago
      > I checked the Chromium source and for Linux they explicitly mention not being allowed to send it externally[0]; they hash it via SHA1, encode it as base64, and use that value. /etc/machine-id seems to be a random value. What purpose does hashing it before sending it do? The hash should still uniquely identify a machine. Am I missing something? Kind of makes me think that it's just done so people say "it's ok, because they're hashing it first, so it's secure!", while in reality hashing doesn't do anything to alleviate any concern.
      - MaulingMonkey 8y ago
        > Am I missing something? The source code links https://www.freedesktop.org/software/systemd/man/machine-id.html https://www.freedesktop.org/software/systemd/man/machine-id.... mentions hashing using an "application-specific key", which would at least make it not correlatable between different apps (so $WEBSITE can't correlate machine IDs with $WELL_BEHAVED_APP 's machine IDs.) But either I'm missing something, or Chromium is - it looks like it's straight up hashing the file and not actually using any application-specific keys!
- JohnFen 8y ago
  But what faster way to discover which applications to remove than by deleting /etc/machine-id?
gvand 8y ago
Why is it there in the first place?
- geofft 8y ago
  https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html 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.
  - LukeShu 8y ago
    > 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. Indeed. If that weren't the case, and the "same kernel" were enough, then things could just use /proc/sys/kernel/random/boot_id.
- JdeBP 8y ago
  See http://jdebp.uk./Softwares/nosh/guide/commands/machine-id.xml#HISTORY http://jdebp.uk./Softwares/nosh/guide/commands/machine-id.xm...
SeriousM 8y ago
Oh, chromium may break? Then I use an alternative. This is true for any other program.
- hedora 8y ago
  Or, devuan could arrange to always use 0xfoad or something appropriate if the file is missing. Even better, it looks like there has been a file that always has the same value for a while; presumably they can just keep that in place.
mirimir 8y ago
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"?
- deleted 8y ago
  [deleted]
- dmurray 8y ago
  It's not clear that would make anyone happy. You might really want to track machines in your fleet, in a way that persists across reboots. Let's say you can access a machine remotely but you got all your ethernet cables tangled up, so you don't know which physical machine you SSHed into. Or if you are being concerned about being tracked by a third party, you don't want this identifier to exist at all, even if it doesn't persist through reboots. I agree there are other solutions in both cases.
- patrickg_zill 8y ago
  So basically deleting the file as the last step before a shut down or reboot will work, is that correct?
  - mirimir 8y ago
    I'll test that. Edit: OK, so I created a Debian VM, noted /etc/machine-id, deleted it, and rebooted. And found that it was still missing. Running systemd-machine-id-setup generated a new machine-id from the D-Bus machine ID. And it was the same as the initial one. But I also see in man machine-id: > The machine-id may also be set, for example when network booting, by setting the systemd.machine_id= kernel command line parameter or passing the option --machine-id= to systemd. A machine-id may not be set to all zeros.
deleted 8y ago
[deleted]
CodeArtisan 8y ago
can't you simply symlink /etc/machine-id to /dev/random?
- mirimir 8y ago
  It seems that you can set a random value at boot. But maybe not whenever it's requested.
- wicket 8y ago
  That won't work because /etc/machine-id is supposed to return a 32 character hex string, but I like the idea. You could do something like this: # rm -f /etc/machine-id # mkfifo /etc/machine-id # while true; do head -c 16 /dev/urandom | od -A n -x | tr -d ' ' > /etc/machine-id; done &
  - wicket 8y ago
    A word of warning. If you try this, make sure the last command is started on boot and runs before D-Bus! I completely forgot I had done this, and I just spent a few hours trying to figure out why my system was hanging on boot. It turns out that D-Bus reads /etc/machine-id on start-up, and naturally by design, it will wait until it receives data from the named pipe before proceeding with execution.
- jlgaddis 8y ago
  Perhaps a better idea (once you strip out the dashes) would be to use a random ID that is automatically (re-)generated on boot: /proc/sys/kernel/random/boot_id
jackewiehose 8y ago
Why would anyone worry that applications like chrome abuse that file? If chrome wants a unique identifier it could generate it itself.
- mirimir 8y ago
  Because the machine-id by default never changes after OS installation.
  - swinglock 8y ago
    Neither does a file Chrome generates. Not even if reinstalled.
    - mirimir 8y ago
      Huh? Even if you do $ sudo apt-get -y purge chrome [or whatever its package name is]? And if necessary, find and delete everything that it created.
      - pantalaimon 8y ago
        apt doesn't know about any file the application might have ever created in your home directory.
        ChristianBundy 8y ago
        > And if necessary, find and delete everything that it created.
        mirimir 8y ago
        Actually, apt does a pretty good job at finding stuff. Sometimes it can't delete, but it warns you about that.
        Evidlo 8y ago
swinglock 8y ago
Removing it just makes it more difficult to write legit programs that has use of such features while anything nefarious will be able to find other things to use as fingerprints, including hardware serials, MACs and their own fingerprint files spread across the filesystem in non-standard locations. Unless the OS is meant to be built for privacy and has a goal to run every app in a sandbox where nothing is fingerprintable, removing easily available fingerprintes would be a disservice to all.
- JohnFen 8y ago
  > Removing it just makes it more difficult to write legit programs Yeah, that's something I simply could not care less about. That said, I don't remove it. I set its permissions so that it isn't world-readable instead.
  - swinglock 8y ago
    Why?
amelius 8y ago
Doesn't a MAC address lookup or disk UUID lookup provide similar fingerprinting capabilities? Even the contents of one's .bashrc file could be used for fingerprinting. I mean, if you start blocking one thing, where do you stop?
- koolba 8y ago
  Ideally you work in reverse and only need to grant access to things to which you want to allow access. Start from zero and let an application provide a manifest of what it wants to access. Ex: * Open outbound TCP sockets * Read from $HOME/.config/chromium * Read from /etc/machine-id It's not a new concept at all and there are multiple approaches for implementing things like this. Getting mass market adoption is sadly next to impossible.
  - amelius 8y ago
    That's basically how smartphones do it. The problem is still that the granularity is not right (except for users who simply want to trust the application). For example, when uploading a photo, I don't want to give Facebook access to my entire filesystem, just the photo that I click. And I don't want to give Facebook access to my camera indefinitely, just now. It will require a lot of design to get security right without deteriorating the UX too much. But I agree, it's better than simply blocking everything.
    - qmarchi 8y ago
      > I don't want to give Facebook access to my entire filesystem, Android's systems of intents and changing how storage security works in Android Q will help with this somewhat. They start expressly prohibiting access to the full filesystem and images and other intent extras must be passed through the intent call, rather than a reference to it on the filesystem.
      - amelius 8y ago
        That sounds great. But what I really want is if the app does want access to the entire filesystem, then the OS will present the app with a sandboxed filesystem, instead of just blocking the app (causing the app to refuse to work, which is what will happen in practice).
salawat 8y ago
What is it with the fetish for inflicting Truenaming in cyberspace? It's incredibly annoying. It needlessly bloats digital footprints, and it creates an opportunity for exploitation by nefarious actors. Leave the Truenaming to the User's that need it. It doesn't do any good being baked in by default. If they really need it, they'll figure out a way to implement it. If they definitely cannot afford it, and aren't aware it is there by default, you are doing more harm putting It in than you would be by leaving well enough alone.
morganvachon 8y ago
Bad title (and I know that fault lies with the source site). At first glance it reads as if the Devuan team is considering embracing/adopting machine IDs, which is counter to their philosophy, when in fact they are against unique identifiers.
kazinator 8y ago
> some applications, such as the Chromium web browser, may report an error if this file is not present Not present, or not present and readable to the application?
kazinator 8y ago
How about making it a symlink to a kernel feature: /etc/machine-id -> /proc/some/path/machine-id this fictitious proc entry that I just invented serves up bullshit content to unprivileged processes, but a true ID to the superuser.
- LukeShu 8y ago
  See also: /proc/sys/kernel/random/boot_id /proc/sys/kernel/random/uuid ---- Because the machine-id is intended to be something that persists between reboots, it is necessarily something that would live in the filesystem, independent of the kernel. Your described functionality could be accomplished with a FUSE filesystem, though. However, that functionality would be problematic. Programs (like D-Bus) expect to be able to use it to identify whether 2 communicating processes are on the same host. If it served different bullshit to each process, it would be entirely non-functional. (Sans returning the true ID to root, this is /proc/sys/kernel/random/uuid) Perhaps instead, use a determined-at-boot value (as the machine-id(5) docs say is acceptable for stateless systems). If this is a kernel construct that isn't associated with a specific (PID?) namespace, then this would also be problematic, as different containers would be considered to be the same "host". (Sans returning the true ID to root, this is /proc/sys/kernel/random/boot_id)
  - kazinator 8y ago
    > it is necessarily something that would live in the filesystem, independent of the kernel. Counterexample: struct utsname and the uname system call.
    - LukeShu 8y ago
      That's a good counterpoint. It would still have to live somewhere in the filesystem, and have a userspace program load it in to the kernel, just as `utsname.nodename` is loaded from /etc/hostname.
      - kazinator 8y ago
privacyhellusa 8y ago
A random machine-id doesnt help. Use a static number instead such as 1111111111111111111111111111111111111111
squarefoot 8y ago
Privacy concerns aside, using the boot device serial number might be a better solution as it can't be deleted or modified and survives reboots and reinstalls. This line will find it easily. Not mine, I simply put together the work of others adding only very small modifications. Needs smartctl (smartmontools package on Debian) which can be run only by root. smartctl -i `df -P / | tail -n 1 | awk '/.*/ { print $1 }'` | egrep ^"Serial Number:" | awk '{print $3}'

57 points by tomkat0789 8y ago

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.

mirimir 8y ago
Sure, but how do you know what programs are misusing it?
- btown 8y ago
  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.
  - nickysielicki 8y ago
    I think this is largely possible with eBPF, if you cared enough.
  - auslander 8y ago
    SELinux or app-armor, keep it in enforcing mode.
- jlgaddis 8y ago
  auditd(8)
  - mirimir 8y ago
    Thanks. https://security.blogoverflow.com/2013/01/a-brief-introduction-to-auditd/ https://security.blogoverflow.com/2013/01/a-brief-introducti...
- yellowapple 8y ago
  Rename it and see which programs complain :)
0815test 8y ago
Or sandbox the program so that it sees a "safe" version of that information.
ez7r6i 8y ago
Chromium reads it, but are we sure it's sending it somewhere? Maybe it uses it for bookkeeping of local sessions or something like that.
- koolba 8y ago
  I checked the Chromium source and for Linux they explicitly mention not being allowed to send it externally[0]; they hash it via SHA1, encode it as base64, and use that value. Interestingly for Windows they pull the machine id from the registry[1] and (at first glance) it doesn't seem like they're doing any hashing. The raw value gets used. Haven't checked if the value gets sent externally but based upon the comment on the Linux code I'd bet it's a yes. [0]: https://github.com/chromium/chromium/blob/aae20fb7d3616de40e2af077bb02aaecb2b13d7f/chrome/browser/policy/browser_dm_token_storage_linux.cc#L89-L111 https://github.com/chromium/chromium/blob/aae20fb7d3616de40e... [1]: https://github.com/chromium/chromium/blob/01a03aab2d89c93c157c9af52dca7ac20d8ed96b/chrome/browser/policy/browser_dm_token_storage_win.cc#L129-L148 https://github.com/chromium/chromium/blob/01a03aab2d89c93c15...
  - jolmg 8y ago
    > I checked the Chromium source and for Linux they explicitly mention not being allowed to send it externally[0]; they hash it via SHA1, encode it as base64, and use that value. /etc/machine-id seems to be a random value. What purpose does hashing it before sending it do? The hash should still uniquely identify a machine. Am I missing something? Kind of makes me think that it's just done so people say "it's ok, because they're hashing it first, so it's secure!", while in reality hashing doesn't do anything to alleviate any concern.
    - MaulingMonkey 8y ago
      > Am I missing something? The source code links https://www.freedesktop.org/software/systemd/man/machine-id.html https://www.freedesktop.org/software/systemd/man/machine-id.... mentions hashing using an "application-specific key", which would at least make it not correlatable between different apps (so $WEBSITE can't correlate machine IDs with $WELL_BEHAVED_APP 's machine IDs.) But either I'm missing something, or Chromium is - it looks like it's straight up hashing the file and not actually using any application-specific keys!
JohnFen 8y ago
But what faster way to discover which applications to remove than by deleting /etc/machine-id?

gvand 8y ago

Why is it there in the first place?

geofft 8y ago
https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html 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.
- LukeShu 8y ago
  > 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. Indeed. If that weren't the case, and the "same kernel" were enough, then things could just use /proc/sys/kernel/random/boot_id.
JdeBP 8y ago
See http://jdebp.uk./Softwares/nosh/guide/commands/machine-id.xml#HISTORY http://jdebp.uk./Softwares/nosh/guide/commands/machine-id.xm...

SeriousM 8y ago

Oh, chromium may break? Then I use an alternative. This is true for any other program.

hedora 8y ago
Or, devuan could arrange to always use 0xfoad or something appropriate if the file is missing. Even better, it looks like there has been a file that always has the same value for a while; presumably they can just keep that in place.

mirimir 8y ago

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"?

deleted 8y ago
[deleted]
dmurray 8y ago
It's not clear that would make anyone happy. You might really want to track machines in your fleet, in a way that persists across reboots. Let's say you can access a machine remotely but you got all your ethernet cables tangled up, so you don't know which physical machine you SSHed into. Or if you are being concerned about being tracked by a third party, you don't want this identifier to exist at all, even if it doesn't persist through reboots. I agree there are other solutions in both cases.
patrickg_zill 8y ago
So basically deleting the file as the last step before a shut down or reboot will work, is that correct?
- mirimir 8y ago
  I'll test that. Edit: OK, so I created a Debian VM, noted /etc/machine-id, deleted it, and rebooted. And found that it was still missing. Running systemd-machine-id-setup generated a new machine-id from the D-Bus machine ID. And it was the same as the initial one. But I also see in man machine-id: > The machine-id may also be set, for example when network booting, by setting the systemd.machine_id= kernel command line parameter or passing the option --machine-id= to systemd. A machine-id may not be set to all zeros.

deleted 8y ago

[deleted]

CodeArtisan 8y ago

can't you simply symlink /etc/machine-id to /dev/random?

mirimir 8y ago
It seems that you can set a random value at boot. But maybe not whenever it's requested.
wicket 8y ago
That won't work because /etc/machine-id is supposed to return a 32 character hex string, but I like the idea. You could do something like this: # rm -f /etc/machine-id # mkfifo /etc/machine-id # while true; do head -c 16 /dev/urandom | od -A n -x | tr -d ' ' > /etc/machine-id; done &
- wicket 8y ago
  A word of warning. If you try this, make sure the last command is started on boot and runs before D-Bus! I completely forgot I had done this, and I just spent a few hours trying to figure out why my system was hanging on boot. It turns out that D-Bus reads /etc/machine-id on start-up, and naturally by design, it will wait until it receives data from the named pipe before proceeding with execution.
jlgaddis 8y ago
Perhaps a better idea (once you strip out the dashes) would be to use a random ID that is automatically (re-)generated on boot: /proc/sys/kernel/random/boot_id

jackewiehose 8y ago

Why would anyone worry that applications like chrome abuse that file? If chrome wants a unique identifier it could generate it itself.

mirimir 8y ago
Because the machine-id by default never changes after OS installation.
- swinglock 8y ago
  Neither does a file Chrome generates. Not even if reinstalled.
  - mirimir 8y ago
    Huh? Even if you do $ sudo apt-get -y purge chrome [or whatever its package name is]? And if necessary, find and delete everything that it created.
    - pantalaimon 8y ago
      apt doesn't know about any file the application might have ever created in your home directory.
      - ChristianBundy 8y ago
        > And if necessary, find and delete everything that it created.
      - mirimir 8y ago
        Actually, apt does a pretty good job at finding stuff. Sometimes it can't delete, but it warns you about that.
        Evidlo 8y ago

swinglock 8y ago

Removing it just makes it more difficult to write legit programs that has use of such features while anything nefarious will be able to find other things to use as fingerprints, including hardware serials, MACs and their own fingerprint files spread across the filesystem in non-standard locations. Unless the OS is meant to be built for privacy and has a goal to run every app in a sandbox where nothing is fingerprintable, removing easily available fingerprintes would be a disservice to all.

JohnFen 8y ago
> Removing it just makes it more difficult to write legit programs Yeah, that's something I simply could not care less about. That said, I don't remove it. I set its permissions so that it isn't world-readable instead.
- swinglock 8y ago
  Why?

amelius 8y ago

Doesn't a MAC address lookup or disk UUID lookup provide similar fingerprinting capabilities? Even the contents of one's .bashrc file could be used for fingerprinting. I mean, if you start blocking one thing, where do you stop?

koolba 8y ago
Ideally you work in reverse and only need to grant access to things to which you want to allow access. Start from zero and let an application provide a manifest of what it wants to access. Ex: * Open outbound TCP sockets * Read from $HOME/.config/chromium * Read from /etc/machine-id It's not a new concept at all and there are multiple approaches for implementing things like this. Getting mass market adoption is sadly next to impossible.
- amelius 8y ago
  That's basically how smartphones do it. The problem is still that the granularity is not right (except for users who simply want to trust the application). For example, when uploading a photo, I don't want to give Facebook access to my entire filesystem, just the photo that I click. And I don't want to give Facebook access to my camera indefinitely, just now. It will require a lot of design to get security right without deteriorating the UX too much. But I agree, it's better than simply blocking everything.
  - qmarchi 8y ago
    > I don't want to give Facebook access to my entire filesystem, Android's systems of intents and changing how storage security works in Android Q will help with this somewhat. They start expressly prohibiting access to the full filesystem and images and other intent extras must be passed through the intent call, rather than a reference to it on the filesystem.
    - amelius 8y ago
      That sounds great. But what I really want is if the app does want access to the entire filesystem, then the OS will present the app with a sandboxed filesystem, instead of just blocking the app (causing the app to refuse to work, which is what will happen in practice).

salawat 8y ago

What is it with the fetish for inflicting Truenaming in cyberspace? It's incredibly annoying. It needlessly bloats digital footprints, and it creates an opportunity for exploitation by nefarious actors. Leave the Truenaming to the User's that need it. It doesn't do any good being baked in by default. If they really need it, they'll figure out a way to implement it. If they definitely cannot afford it, and aren't aware it is there by default, you are doing more harm putting It in than you would be by leaving well enough alone.

morganvachon 8y ago

Bad title (and I know that fault lies with the source site). At first glance it reads as if the Devuan team is considering embracing/adopting machine IDs, which is counter to their philosophy, when in fact they are against unique identifiers.

kazinator 8y ago

> some applications, such as the Chromium web browser, may report an error if this file is not present Not present, or not present and readable to the application?

kazinator 8y ago

How about making it a symlink to a kernel feature: /etc/machine-id -> /proc/some/path/machine-id this fictitious proc entry that I just invented serves up bullshit content to unprivileged processes, but a true ID to the superuser.

LukeShu 8y ago
See also: /proc/sys/kernel/random/boot_id /proc/sys/kernel/random/uuid ---- Because the machine-id is intended to be something that persists between reboots, it is necessarily something that would live in the filesystem, independent of the kernel. Your described functionality could be accomplished with a FUSE filesystem, though. However, that functionality would be problematic. Programs (like D-Bus) expect to be able to use it to identify whether 2 communicating processes are on the same host. If it served different bullshit to each process, it would be entirely non-functional. (Sans returning the true ID to root, this is /proc/sys/kernel/random/uuid) Perhaps instead, use a determined-at-boot value (as the machine-id(5) docs say is acceptable for stateless systems). If this is a kernel construct that isn't associated with a specific (PID?) namespace, then this would also be problematic, as different containers would be considered to be the same "host". (Sans returning the true ID to root, this is /proc/sys/kernel/random/boot_id)
- kazinator 8y ago
  > it is necessarily something that would live in the filesystem, independent of the kernel. Counterexample: struct utsname and the uname system call.
  - LukeShu 8y ago
    That's a good counterpoint. It would still have to live somewhere in the filesystem, and have a userspace program load it in to the kernel, just as `utsname.nodename` is loaded from /etc/hostname.
    - kazinator 8y ago

privacyhellusa 8y ago

A random machine-id doesnt help. Use a static number instead such as 1111111111111111111111111111111111111111

squarefoot 8y ago

Privacy concerns aside, using the boot device serial number might be a better solution as it can't be deleted or modified and survives reboots and reinstalls. This line will find it easily. Not mine, I simply put together the work of others adding only very small modifications. Needs smartctl (smartmontools package on Debian) which can be run only by root. smartctl -i `df -P / | tail -n 1 | awk '/.*/ { print $1 }'` | egrep ^"Serial Number:" | awk '{print $3}'