feat: bind mount /etc/machine-id read-only

[matthewwardrop]

I recently started working with intune, and was frustrated that the machine-id kept changing as I fixed issues I was finding (when recreate failed). I don't know if this is something you would want to upstream, but I like the stability offered by propagating the true machine id into the container. Perhaps there are good reasons not to do this.

[bketelsen]

interesting. I'm not really sure whether there are any broad implications here. Seems reasonable though at a first glance.

[bketelsen]

I asked Claude to research @matthewwardrop and here's what it said:

 What actually consumes machine-id in the container                                                                                                    
                                                                                                                                                       
 strings on the image binaries:                                                                                                                        
                                                                                                                                                       
 - intune-agent, intune-portal: literal /etc/machine-id plus GetDpti: Failed to read machine-id from file. — Intune's device platform identity (DPTI)  
   is derived from /etc/machine-id.                                                                                                                    
 - intune-daemon (zbus): "/var/lib/dbus/machine-id" "/etc/machine-id" and Failed to read from /var/lib/dbus/machine-id or /etc/machine-id — D-Bus      
   reads /var/lib/dbus/machine-id first.                                                                                                               
                                                                                                                                                       
 So this file is the Intune device identity, not cosmetic state.                                                                                       
                                                                                                                                                       
 Problems with --bind-ro=/etc/machine-id                                                                                                               
                                                                                                                                                       
 1. Device identity collision with the host. The container would present the host's identity to Intune/Entra. If the host is itself enrolled — the     
    exact two-tenant setup intuneme mcp exists for, per AGENTS.md — you get two device objects claiming one DPTI. Whatever Microsoft does in that      
    case, nobody wants to find out on a compliance-gated machine.                                                                                      
 2. Silently re-identifies every existing enrolled container. The bind is unconditional in buildBootArgs, so the next intuneme start after upgrading   
    the CLI changes DPTI mid-enrollment. No opt-out, no migration, no recreate required to trigger it. At minimum this needs a config key defaulting   
    off.                                                                                                                                               
 3. It only half-applies. The image ships /var/lib/dbus/machine-id as a separate regular file, not a symlink to /etc/machine-id:                       
    ```                                                                                                                                                
-rw-r--r-- 1 root root 33 /etc/machine-id
-rw-r--r-- 1 root root 33 /var/lib/dbus/machine-id
    ```                                                                                                                                                
    After the bind, /etc/machine-id = host id (Intune DPTI) while /var/lib/dbus/machine-id = image id (D-Bus GUID). Two different machine identities   
    inside one container, which is worse than either value consistently. Fixing that needs an image change (ln -sf /etc/machine-id                     
    /var/lib/dbus/machine-id), which the PR doesn't make.                                                                                              
 4. It contradicts the isolation model. Everything else bound in is a device or socket the container needs to render/authenticate. Host identity is    
    not that, and it leaks into a container whose whole job is running vendor telemetry.                                                               
                                                                                                                                                       
 The reported symptom has a different root cause                                                                                                       
                                                                                                                                                       
 The id isn't drifting randomly — it's baked into the OCI image:                                                                                       
                                                                                                                                                       

image ghcr.io/frostyard/ubuntu-intune:insiders /etc/machine-id = 8d8893b95e2b437a95aa19a178dede84
local ~/.local/share/intuneme/rootfs/etc/machine-id = 8d8893b95e2b437a95aa19a178dede84 (host: 7d6e8a5a…)

                                                                                                                                                      
dpkg ran systemd-machine-id-setup at image build time and nothing in ubuntu-intune/build_files/ clears it (repo-wide grep for machine-id returns zero 
matches). Consequences: it's stable across boots, changes on every recreate onto a rebuilt image — the author's complaint — and is identical for      
every intuneme user on the same tag, which is its own latent Intune-identity bug worth an issue.                                                      
                                                                                                                                                      
The fix that matches the repo's existing patterns:                                                                                                    
                                                                                                                                                      
- ubuntu-intune/build_files/build: truncate -s 0 /etc/machine-id and ln -sf /etc/machine-id /var/lib/dbus/machine-id — the documented systemd         
  first-boot convention, so nspawn/PID1 generates a unique id per install and persists it in the rootfs.                                              
- cmd/recreate.go + internal/provision/backup.go: preserve the existing /etc/machine-id across rootfs re-extraction, exactly like                     
  BackupDeviceBrokerState and BackupShadowEntry already preserve broker state and the shadow entry.                                                   
                                                                                                                                                      
That gives the author the stability he wants — a per-install identity that survives recreate — without borrowing the host's. I'd reply on #196 along  
those lines and close it in favor of that. I did not touch your running intuneme container to test any of this.         ```

[matthewwardrop]

Yeah. The machine-id is baked into the image, but I did find myself having to nuke the setup a few times during development; which then registered a "new" machine each time. I don't have super strong feelings about this :).

On my system I ended up switching over to Himmelblau, once I got it working... so I don't have much skin in the game either. Maybe make an option to pass in a static machine-id or something. I'm glad I was able to get Intuneme working, though, as a backup in case my other approach ceases to work :). Thanks for your excellent work here!