# File /etc/machine-id

## figueroa

Discussion referenced in the news at Distrowatch:

https://distrowatch.com/weekly.php?issue=20190311#news

references a file /etc/machine-id being discussed by Devuan team.

I have that file, the same one since 18 November 2017, readable by anybody. Isn't this a security risk for snooping software? It's like I've been fingerprinted. I don't want such a file. Is anybody doing anything about this? I don't run systemd.

----------

## Ant P.

You can delete it at shutdown if you want, dbus will recreate it with a different value at the next boot.

If you're worried about snooping software, don't install any.

----------

## bunder

zfs uses something similar, /etc/hostid...  but it's based off your ip address, and if you're using 192.168.x.x, there's nothing to be worried about there because its really not identifying.  

it looks like you can also define them both on the kernel line, so you could always change them up every few weeks as well.

----------

## figueroa

 *Ant P. wrote:*   

> You can delete it at shutdown if you want, dbus will recreate it with a different value at the next boot.
> 
> If you're worried about snooping software, don't install any.

 

That's not a good answer. We Gentoo users, and many other Linux users, are being fingerprinted with that file. Why isn't there a standard, default, shutdown script that deletes that file automatically? Why should it have permission read by all anyway? This is a bad thing.

----------

## figueroa

 *bunder wrote:*   

> it looks like you can also define them both on the kernel line, so you could always change them up every few weeks as well.

 

It would be great to have a reference for that kernel line. An Internet search for /etc/machine-id does not bring up a lot of help.

----------

## bunder

 *figueroa wrote:*   

>  *bunder wrote:*   it looks like you can also define them both on the kernel line, so you could always change them up every few weeks as well. 
> 
> It would be great to have a reference for that kernel line. An Internet search for /etc/machine-id does not bring up a lot of help.

 

it was linked in the article you posted... https://www.freedesktop.org/software/systemd/man/machine-id.html

 *Quote:*   

> The machine ID may be set, for example when network booting, with the systemd.machine_id= kernel command line parameter or by passing the option --machine-id= to systemd. An ID is specified in this manner has higher priority and will be used instead of the ID stored in /etc/machine-id.

 

----------

## figueroa

 *bunder wrote:*   

> it was linked in the article you posted... https://www.freedesktop.org/software/systemd/man/machine-id.html
> 
>  *Quote:*   The machine ID may be set, for example when network booting, with the systemd.machine_id= kernel command line parameter or by passing the option --machine-id= to systemd. An ID is specified in this manner has higher priority and will be used instead of the ID stored in /etc/machine-id. 

 

Thank you for that, but I don't network boot or have systemd installed. I've never had systemd installed.

----------

## Hu

Rather than deleting it, wouldn't it be better to patch the offending program(s) not to create it?  That would be better than assuming you will reboot often enough to clear it routinely.  Failing that, patch them to store it somewhere that is automatically cleared, like /run or a directory under management of a tmpreaper.

----------

## pjp

Seems dbus really wants it.

```
$ grep machine-id /etc/init.d/dbus 

        /usr/bin/dbus-uuidgen --ensure=/etc/machine-id
```

  *man dbus-uuidgen wrote:*   

>              dbus-uuidgen --ensure
> 
>        This will ensure that /var/lib/dbus/machine-id exists and has the uuid in it. It won't overwrite an existing uuid, since this id should
> 
>        remain fixed for a single machine until the next reboot at least.
> ...

  Also, /etc/lvm/lvm.conf may reference /etc/machine-id to use as lvm's system-id.

----------

## eccerr0r

If you're running systemd/journald, the machine id is used to select which directory the logs go to.

There's a lot more things you can get from the machine that uniquely identifies it (ifconfig doesn't need root and can get your MAC address for one), though one more is not good.  Any one tried making this file unreadable to the world?

----------

## Ant P.

 *figueroa wrote:*   

>  *Ant P. wrote:*   You can delete it at shutdown if you want, dbus will recreate it with a different value at the next boot.
> 
> If you're worried about snooping software, don't install any. 
> 
> That's not a good answer. We Gentoo users, and many other Linux users, are being fingerprinted with that file. Why isn't there a standard, default, shutdown script that deletes that file automatically? Why should it have permission read by all anyway? This is a bad thing.

 

Fingerprinted by whom? You have all the tools you need to produce a satisfactory answer to that question, show some initiative. Which malware did you install, so that the rest of us know to avoid it?

If you're that paranoid about fingerprinting, then you'd better make sure you close all the other avenues of attack:

remove networking (you probably haven't secured net.ipv6.conf.all.use_tempaddr, have you?)

don't have world-readable /dev/ (ls -l /dev/*/by-*/ looks juicy, doesn't it?)

ditto for /proc/ (have you anonymised your /proc/version yet?)

remove /sys/ (what does your DMI data say about you? Have you shuffled your PCI cards lately?)

shred /etc/ (your make.conf is probably unique!)

remove $HOME (if apps can access this, it's already game over)

And why even use Linux at all if you're going to blindly assume bad faith in the developers of all the software you're using?

Do the most basic level of research before you fly into histrionics like this.

----------

## arnvidr

Perfect is the enemy of good, so that's a whole lot of irrelevant points you're making.

And fingerprinted by dbus, obviously. Still not adequately explained why this id is necessary.

I added a rm to the dbus init script shutdown routine, since it is responsible for re-creating it at boot-time anyway. I found some references to others having the file on a tmpfs, which would accomplish the same thing. It's a reasonable compromise until an explanation is found for *why* it is bad to change it while the system is running.

----------

## eccerr0r

 *machine-id on freedesktop wrote:*   

> 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. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm.

 

Chrome is the untrusted application here, according to the attached thread.  Anyone know what chromium is doing with the machine id?

----------

## krinn

oh so that ultra secure machineid is protect and to use it i must do

sd_id1000000010101000243000_get_machine_app_specific_ultra_secure_cryptic() {

cat /etc/machine-id

}

that's their vision of security?

----------

## figueroa

 *pjp wrote:*   

> Seems dbus really wants it.
> 
> ```
> $ grep machine-id /etc/init.d/dbus 
> 
> ...

 

Thanks, I hadn't quite gotten that far. That's how it gets created if it doesn't exist. It would seem to be a good thing to add "rm /etc/machine-id" to a .stop file in /etc/local.d/. Then, at least, I get a fresh number each time I reboot, which isn't often, but it plugs one more privacy hole, since the use of this file is not living up to its documentation.

I don't want to edit the dbus init file because that will just get changed when updating.

Sure, there are lots of ways to be fingerprinted over the network but one less would be good.

----------

## figueroa

 *Ant P. wrote:*   

> Do the most basic level of research before you fly into histrionics like this.

 

I'm just an overdeveloped user and appreciate your contribution, even though you were not encouraging. I found something I thought was worth sharing, so I did, and I thought I might get a little help here, which I have.

----------

## mike155

 *Quote:*   

> This ID uniquely identifies the host. It should be considered "confidential"
> 
> 

 

The machine-id doesn't seem to be very "confidential". On every machine I looked at, everyone can read it:

```
-rw-r--r-- 1 root root 33  Oct 26 2011  /etc/machine-id

```

Stranger still, the file has the same 'last modification date' on most machines I looked at: Oct 26 2011 - even if the machine was installed only a few weeks ago...

----------

## figueroa

 *mike155 wrote:*   

> Stranger still, the file has the same 'last modification date' on most machines I looked at: Oct 26 2011 - even if the machine was installed only a few weeks ago...

 

I do have an Oct 26, 2011, but my newer x86_64 machine, /etc/machine-id date matches the installation date Nov 18, 2017.

----------

## eccerr0r

I think I'm going to chmod it and see what breaks in userland, they should not be using it, IMHO.

-edit-

Hmm.  The data appears to be available in dbus anyway (so it seems anything that talks to dbus has the potential to use it).  So we have to trust the applications that we run... surprise surprise...

----------

## figueroa

 *eccerr0r wrote:*   

> I think I'm going to chmod it and see what breaks in userland, they should not be using it, IMHO.
> 
> Hmm.  The data appears to be available in dbus anyway (so it seems anything that talks to dbus has the potential to use it).  So we have to trust the applications that we run... surprise surprise...

 

Making machine-id root read-only causes log errors in lightdm in MX Linux (Debian based). But lightdm still works as expected. I didn't bother trying this in Gentoo, my main system.

Deleting the file /etc/machine-id at shutdown via /etc/local.d/ *.stop file works as expected and a new one is created upon reboot by the dbus init file. That works without error. I've done it, and I like it, even though I don't reboot very often (months).

It seems strange to me that since Gentoo, being a non-systemd-centric distribution, that the dbus init file creates or re-creates /etc/machine-id (a systemd thing) rather than /var/lib/dbus/machine-id (which is a dbus thing) and that /var/lib/dbus/machine-id is by default a symlink to /etc/machine-id. That strikes me as totally backwards systemd thinking. How did that happen?

----------

## Ant P.

Where do you get that systemd owns this file from?

----------

## figueroa

 *Ant P. wrote:*   

> Where do you get that systemd owns this file from?

 

For the /etc/machine-id here: https://www.freedesktop.org/software/systemd/man/machine-id.html

----------

## Naib

 *figueroa wrote:*   

>  *Ant P. wrote:*   Where do you get that systemd owns this file from? 
> 
> For the /etc/machine-id here: https://www.freedesktop.org/software/systemd/man/machine-id.html

 which comes from dbus

----------

## figueroa

 *Naib wrote:*   

>  *figueroa wrote:*    *Ant P. wrote:*   Where do you get that systemd owns this file from? 
> 
> For the /etc/machine-id here: https://www.freedesktop.org/software/systemd/man/machine-id.html which comes from dbus

 No, best I can tell, /var/lib/dbus/machine-id comes from dbus. If not, show me.

----------

## Ant P.

/etc/init.d/dbus

----------

## AJM

 *figueroa wrote:*   

> No, best I can tell, /var/lib/dbus/machine-id comes from dbus. If not, show me.

 

```
ls -lh /var/lib/dbus/machine-id

lrwxrwxrwx 1 root root 15 Feb 26 20:08 /var/lib/dbus/machine-id -> /etc/machine-id
```

Never have (and never will) had systemd anywhere near this PC.  I generally have dbus disabled too for that matter, though it's installed... I too was slightly disturbed when I found machine-id, about the start of the year - I was clearing out the cruft accumulated in /etc from many changes over the years and couldn't recall ever having heard of it.

----------

## figueroa

 *Ant P. wrote:*   

> /etc/init.d/dbus

 

I agree. Why is dbus-uuidgen --ensure invoked with a non-default machine-id destination? The default destination is /var/lib/dbus. /etc/machine-id belongs to systemd. ADDED: see man dbus-uuidgen

----------

## Ant P.

 *figueroa wrote:*   

> Why is dbus-uuidgen --ensure invoked with a non-default machine-id destination?

 

Because several programs need the file, as was already pointed out for LVM. Avahi and pulseaudio do too.

Less devuan/phoronix stereotypical religious rhetoric, more hard facts please. I've yet to see any evidence of this wild "spying" claim.

----------

## figueroa

 *Ant P. wrote:*   

> Less devuan/phoronix stereotypical religious rhetoric, more hard facts please. I've yet to see any evidence of this wild "spying" claim.

 

I don't think you see the big picture. Why the verbal hostility? Following the documentation, dbus should put machine-id in /var/lib/dbus/ then making a symlink /etc/machine-id to /var/lib/dbus/machine-id for those programs that need it makes the most sense in a system that does not run systemd, not the other way around having dbus use a non-default location for it's machine-id file and symlinking back to that.

I haven't made any wild spying claims, but a non-permanent machine-id, since one appears to be required, rather than a permanent fingerprint makes the most sense. It's nuts that this isn't implemented by default.

I'm going to plug one hole at a time as I become aware of them while trying to maintain a serviceable compliant desktop system.

----------

## pjp

 *Ant P. wrote:*   

> Because several programs need the file, as was already pointed out for LVM. Avahi and pulseaudio do too.

  LVM _may_ use it, but will do without. 

```

        # Configuration option global/system_id_source.

        # The method LVM uses to set the local system ID.

        # Volume Groups can also be given a system ID (by vgcreate, vgchange,

        # or vgimport.) A VG on shared storage devices is accessible only to

        # the host with a matching system ID. See 'man lvmsystemid' for

        # information on limitations and correct usage.

        # 

        # Accepted values:

        #   none

        #     The host has no system ID.

        #   lvmlocal

        #     Obtain the system ID from the system_id setting in the 'local'

        #     section of an lvm configuration file, e.g. lvmlocal.conf.

        #   uname

        #     Set the system ID from the hostname (uname) of the system.

        #     System IDs beginning localhost are not permitted.

        #   machineid

        #     Use the contents of the machine-id file to set the system ID.

        #     Some systems create this file at installation time.

        #     See 'man machine-id' and global/etc.

        #   file

        #     Use the contents of another file (system_id_file) to set the

        #     system ID.
```

Some background info related to the change, at least as far as it concerns Gentoo. Per the ebuild:  *dbus-1.10.24.ebuild wrote:*   

>         # Ensure unique id is generated and put it in /etc wrt #370451 but symlink
> 
>         # for DBUS_MACHINE_UUID_FILE (see tools/dbus-launch.c) and reverse
> 
>         # dependencies with hardcoded paths (although the known ones got fixed already)

   *#370451 wrote:*   

> I'd appreciate if along with this bump, we could switch to using /etc/machine-id for D-Bus machine id (either by moving /var/lib/dbus/machine-id to that or removing the old one and getting a new one). That would simplify the systemd ebuild a little.

 

I'm no ebuild writer, but this one seems simple enough (famous last words). This patch is untested, but I do plant to test it eventually. If it works, I'll probably tweak it to use variables and one set of commands to do the work. Although I may prefer a script that corrects it independent of the ebuild. Maintaining ebuilds to reduce systemd fallout isn't on my bucket list.

```
--- old/dbus-1.10.24.ebuild     2019-03-15 22:02:42.929391869 -0000

+++ new/dbus-1.10.24.ebuild     2019-03-15 22:01:26.137392931 -0000

@@ -234,8 +234,13 @@

        # Ensure unique id is generated and put it in /etc wrt #370451 but symlink

        # for DBUS_MACHINE_UUID_FILE (see tools/dbus-launch.c) and reverse

        # dependencies with hardcoded paths (although the known ones got fixed already)

-       dbus-uuidgen --ensure="${EROOT}"/etc/machine-id

-       ln -sf "${EPREFIX}"/etc/machine-id "${EROOT}"/var/lib/dbus/machine-id

+       if use systemd ; then

+               dbus-uuidgen --ensure="${EROOT}"/etc/machine-id

+               ln -sf "${EPREFIX}"/etc/machine-id "${EROOT}"/var/lib/dbus/machine-id

+       else

+               dbus-uuidgen --ensure="${EROOT}"/var/lib/dbus/machine-id

+               ln -sf "${EROOT}"/var/lib/dbus/machine-id "${EPREFIX}"/etc/machine-id

+       fi

 

        if [[ ${CHOST} == *-darwin* ]]; then

                local plist="org.freedesktop.dbus-session.plist"
```

----------

## Akkara

I wonder why the need for an id in the first place.  Someone had to make that decision at some point and put in it.  What problem were they solving?  I tried to do some quick searches but most of what I get is bug reports along the lines of "it is required can we have it get generated please".  Didn't find any statement of motivation for it.

I don't know much about systemd, dbus, and all that.  But I am a big fan of keeping things as simple as possible unless reason is shown for needing something more complicated.  And it seems to me, if you can open a local socket and talk to a service, you implicitly know both must be running on the same machine, without needing to ID anything.  Much like if we can shake hands, we must be in the same room, no need to check the GPS coordinates.  :Smile: 

Does dbus work across the network?  (And if so, what does it do that needs that?)  I know pulseaudio can play across the network maybe that has something to do with it.  If one doesn't use pulseaudio does that dependency go away?  Sorry just talking out loud here, and while I could go on and investigate all this more deeply, it seems like a huge timesink to be keeping up with all the potential issues that the constant flux of software brings.  Alas it is much easier for one guy to write bad code than for a team of ten to go in and find the bugs and fix the bad architectural decisions.

----------

## eccerr0r

The ID is for having shared storage space.

Temp files in machine unique /tmp have notoriously been security issues.  So it's best to store temp files in user accounts.

However if you have multiple machine sharing the same directory with multiple logins...collision city!  So what do you do?   Unique machine ID.  Granted a hostname usually is sufficient, but I suspect the machine ID is used in case dynamic IP is used and changes from time to time.

Dbus can be used over network, it has always been for IPC and well, processes can be running on different computers too.  Yes these features were designed for clustering in mind, us with single PCs it's kind of useless...

----------

## pjp

 *eccerr0r wrote:*   

> The ID is for having shared storage space.
> 
> Temp files in machine unique /tmp have notoriously been security issues.  So it's best to store temp files in user accounts.
> 
> However if you have multiple machine sharing the same directory with multiple logins...collision city!  So what do you do?   Unique machine ID.  Granted a hostname usually is sufficient, but I suspect the machine ID is used in case dynamic IP is used and changes from time to time.
> ...

  Thanks for the details. Sounds like a great opportunity to make that optional for those who actually use it in a cluster (or optional for those who don't, depending on your pov).

----------

## eccerr0r

Well, if you want to workaround this by randomly select a host id, that's probably the finest workaround; but really you need to trust your software.  I'd think Pulseaudio is exempt because it's necessary to keep track of these sessions.  Likewise Avahi, to keep machines from stepping on each other if IP address changes from DHCP so other machines can keep track of services available.  LVM is reasonable too if you move disks around between machines, makes it easier for the subsystem to ensure similarly configured disks aren't accidentally swapped between machines.

Chrome however should have no right to this information, at least to the non-hash version.  It's explicitly improper usage if the purpose is to upload it to the mothership.  I don't see a reason why it would need the ID to detect collisions between multiple instances, this was a problem solved without machine id just fine for years.

IMHO I'm just going to leave it.  Unfortunately I am a bit alarmed about the Chrome usage of this id.  The other software above I have no problems with, even journald which also uses it.  Fortunately I don't use Chrome much (it's in its own VM that I use for only one specific website), so hopefully this limits exposure.

----------

## pjp

 *eccerr0r wrote:*   

> Well, if you want to workaround this by randomly select a host id, that's probably the finest workaround; but really you need to trust your software.  I'd think Pulseaudio is exempt because it's necessary to keep track of these sessions.  Likewise Avahi, to keep machines from stepping on each other if IP address changes from DHCP so other machines can keep track of services available.  LVM is reasonable too if you move disks around between machines, makes it easier for the subsystem to ensure similarly configured disks aren't accidentally swapped between machines.
> 
> Chrome however should have no right to this information, at least to the non-hash version.  It's explicitly improper usage if the purpose is to upload it to the mothership.  I don't see a reason why it would need the ID to detect collisions between multiple instances, this was a problem solved without machine id just fine for years.
> 
> IMHO I'm just going to leave it.  Unfortunately I am a bit alarmed about the Chrome usage of this id.  The other software above I have no problems with, even journald which also uses it.  Fortunately I don't use Chrome much (it's in its own VM that I use for only one specific website), so hopefully this limits exposure.

  I think the trust issue is separate. Although, despite making the statement "you need to trust your software," it sounds like you might not trust Chrome?

My suggestion was related to software allowing the ability to choose whether or not to configure support for various features such as audio, dhcp, lvm. /usr/portage/profiles/use.desc has 371 entries.

----------

## figueroa

 *eccerr0r wrote:*   

> Well, if you want to workaround this by randomly select a host id, that's probably the finest workaround;

 

For the time being, I like my solution:

 *Quote:*   

> Deleting the file /etc/machine-id at shutdown via /etc/local.d/ *.stop file works as expected and a new one is created upon reboot by the dbus init file. That works without error. I've done it, and I like it, even though I don't reboot very often (months). 

 

This is now tested on two systems, works fine, and is compliant with dbus documentation that indicated that machine-id should not be changed while running. I have created a similar but slightly more convoluted fix in two MX Linux systems that also works fine and tested on two systems.

----------

## eccerr0r

 *pjp wrote:*   

> I think the trust issue is separate. Although, despite making the statement "you need to trust your software," it sounds like you might not trust Chrome?
> 
> 

 

Indeed I do not trust the chrome binary, hence it's in a VM.

 *Quote:*   

> My suggestion was related to software allowing the ability to choose whether or not to configure support for various features such as audio, dhcp, lvm. /usr/portage/profiles/use.desc has 371 entries.

 

And of course the problem of having to maintain more than one version of ensuring no temp file collisions.  Yes it's a cop out, but in this case the same code stream works regardless if you're on a cluster or single computer.  Just needs to be better protected from programs that have no need for unique ID.

 *figueroa wrote:*   

>  *eccerr0r wrote:*   Well, if you want to workaround this by randomly select a host id, that's probably the finest workaround; 
> 
> For the time being, I like my solution:
> 
>  *Quote:*   Deleting the file /etc/machine-id at shutdown via /etc/local.d/ *.stop file works as expected and a new one is created upon reboot by the dbus init file. That works without error. I've done it, and I like it, even though I don't reboot very often (months).  
> ...

 

Effectively you are choosing a random host ID as it creates a new one each time.  However I'd suggest you reboot your machine more often to get a different ID more frequently, at least that's what I'd do if I had to deal with a program leaking this information out onto the network like chrome.  For my use of chrome, as long as I look like I am a robot doing the same single repetitive task over and over again and nothing else -- no searches, no website reading, nothing else --- I doubt the mothership can glean much information from that.

----------

## mike155

 *Quote:*   

> This is now tested on two systems, works fine, and is compliant with dbus documentation that indicated that machine-id should not be changed while running. I have created a similar but slightly more convoluted fix in two MX Linux systems that also works fine and tested on two systems.

 

What about the MAC address(es) of your network interface(s)? How do you change them? And what about the UUID of your boot, root and data partitions? And what about the serial number of your mainboard/BIOS?

----------

## figueroa

 *mike155 wrote:*   

> 
> 
> What about the MAC address(es) of your network interface(s)? How do you change them? And what about the UUID of your boot, root and data partitions? And what about the serial number of your mainboard/BIOS?

 

One hole at a time. machine-id has been shown to be abused.  What evidence can you demonstrate that these other markers are being abused?

----------

## figueroa

 *eccerr0r wrote:*   

> 
> 
> However I'd suggest you reboot your machine more often to get a different ID more frequently, at least that's what I'd do if I had to deal with a program leaking this information out onto the network like chrome.

 

Probably not going increase booting. I'm not using Chrome or Chromium. The "Chrome call Home" baloney is outrageous.

----------

## eccerr0r

So the question remains, why is it peeking at /etc/machine-id ... ?

----------

## Naib

 *figueroa wrote:*   

>  *mike155 wrote:*   
> 
> What about the MAC address(es) of your network interface(s)? How do you change them? And what about the UUID of your boot, root and data partitions? And what about the serial number of your mainboard/BIOS? 
> 
> One hole at a time. machine-id has been shown to be abused.  What evidence can you demonstrate that these other markers are being abused?

 where?

----------

## pjp

 *eccerr0r wrote:*   

> And of course the problem of having to maintain more than one version of ensuring no temp file collisions.  Yes it's a cop out, but in this case the same code stream works regardless if you're on a cluster or single computer.  Just needs to be better protected from programs that have no need for unique ID.

  I mostly agree, just not with the sole solution of some definition for "better" protected. Better works until it doesn't. -no-machineid solves the problem. And if security is the reason to "better protect" the id, then security is also the reason to not require one. So for me, as long as it is required, it is as trustworthy to me as Chrome is to you. For now, I'm stuck with it. But I think I can recompile without dbus and maybe remove anything that requires it.

----------

## figueroa

 *Naib wrote:*   

> where?

 

In the documentation for machine-id " It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network." Chromium (and Chrome?) reads it and throw and error if it's not there.

----------

## Akkara

Thank you, eccerr0r, for the detailed explanation.

 *eccerr0r wrote:*   

> The ID is for having shared storage space.
> 
> Temp files in machine unique /tmp have notoriously been security issues.  So it's best to store temp files in user accounts.

 

I had watched in dismay the migration of temp files to the user's home in response to possible security issues.  The main problem, as I understand it, is the possibility that a different user's malicious program could create a file (or a symlink) by the same name in /tmp, and then your program goes to open and use it but the different owner/permissions allow the other program to access the contents.  By moving temporaries to the user's home, it was reasoned, would prevent this attack because others wouldn't be able to write into another's home.  Of course, if you were tricked into running the malicious program in the first place, this doesn't help.  It is only to mitigate damage if some daemon or something were somehow compromised.  A reasonable goal, but it seems they used a unnecessarily heavy hammer to reach it.

A better solution, in my opinion, would be making a directory such as "/tmp/home-${USER}-tmp" upon logging in, and put the user's temp stuff there.  Check that it isn't a symlink, make sure it is owned by the named user, make it mode 700, and no one (other than root) should be able to read or mess with the contents.  And there are no collisions to worry about, since by definition /tmp is private to each machine.

Instead they choose to put it in home.  Why??  Was an idea like the one I just mentioned not considered?  Was it considered of and rejected for a reason?  (What was that reason?)  The /tmp directory is often mounted as tmpfs, making it ideal for ... temporary things!  While home is on some kind of mass storage device.  If that happens to be a hard-disk, it slows everything down as accesses to your files and access to the temporary workspace vie for bandwidth.  If that happens to be a SSD, it uses up write cycles needlessly writing back stuff that will be deleted as soon as whatever program you're using exits.  And if home happens to be nfs-mounted (which would be the case if they are having to worry about collisions), you get additional latency and slowdowns working across the net on top of all that.

I having been using a hand-rolled jury-rigged version of the "home-${USER}-tmp" solution myself.  Didn't polish it, there's no elegant scripts, just a few lines in .bashrc to make the directory at login if it isn't there, and check that the user and modes are what they should be.  Then I had gone thru all my dot-files looking for the places where programs stored their temps, and symlinked those to "/tmp/home-${USER}-tmp/${subdir}", after adding a few more lines to .bashrc to make those subdirectories.  Also put all those thumbnails directories in there while I was at it.  So now when I open gimp, or audacity, or any other program that uses large amounts to temporary storage, it opens right away and it isn't causing massive traffic to the SSD and using up write cycles, when there are plenty of gigabytes sitting unused in /tmp's tmpfs.

I continue to be surprised how seemingly less-optimal solutions seem to be chosen, which then requires additional changes to get around the problems the first solutions caused.  But, maybe I'm being myopic and not seeing the larger problems outside of my own little world.  I welcome to be informed about it, if that is the case.

----------

## krinn

a non solve to the problem.

If you move files to home directory to protect them from other users, the same could be achieve with proper rights and owernship on the file in /tmp ; i don't see where it could be problem as malicious program would need to have rights to alter it too.

If it was to create some sharing, i don't see how it help solving the problem to move the file into user home, as it should be restrict area from others too.

(without even speaking about other issue it could add, root have always a minimum space protect by fs to limit out of space issue, home have no such protection for users, a bad and kept open tmp file in home may put out of space home directory and user loosing valuable datas because of a crappy program filing his space with crap tmp datas)

And my first message about it was to point out, that there's no security at all in crypting a file that anyone could read ; it's even worst because from a privacy point of view, the crypted file is of lower value (depeding how you crypt it the result may change, while the original one, crypt or not, if you can source it and its content never change is golden value). Nobody cares how machine-id content is generated, as long as you can read it and it never change, it's gold.

So there's no security given by machine-id, only a 100% good fingerprint given to spys.

----------

## eccerr0r

Well, the name in /tmp would need to be randomized.  If another user started creating a /tmp/home-$otheruser-tmp/ directory, that would cause pain.  In someone elses home directory, it's difficult to create such directory.  Putting it in /home also enforces quota on temp space...

I suspect that the /run/user/$ID/* was created by systemd-logind/consolekit to mitigate this.  I'm not sure why pulseaudio doesn't use this directory, that seems more logical.

I'm not 100% sure of avahi's capabilities are (namely the possibility of unprivileged services) and don't know what this may entail but advertising a service on a host that changed their IP address, it would be nice to know which machine you were running on, and the machine id would be helpful.  Again this would hopefully be a trusted LAN environment so these don't go out on the open network.

LVM is a different problem.

----------

