Bug #13623

Executable bits of /etc/hostname not set deterministically

Added by anonym 2017-08-13 16:03:07 . Updated 2017-09-28 18:50:08 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Build system
Target version:
Tails_3.2
Start date:
2017-08-13
Due date:
% Done:

100%

Feature Branch:
bugfix/13623-reproducible-etc-hostname-permissions
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:
289

Description

During our call for reproduction it was reported that the executable bits (for all of ugo) of /etc/hostname is not set deterministically and hence breaks Tails’ reproducibility.

diffoscope report:

├── live/filesystem.squashfs
│ ├── unsquashfs -d '' -lls {}
│ │ @@ -1169,15 +1169,15 @@
│ │  -rw-r--r-- root/root               177 2016-12-04 20:37 /etc/gss/mech.d/README
│ │  drwxr-xr-x root/root                41 2017-08-05 13:25 /etc/gtk-2.0
│ │  -rw-r--r-- root/root               890 2017-01-26 16:59 /etc/gtk-2.0/im-multipress.conf
│ │  drwxr-xr-x root/root                41 2017-08-05 13:25 /etc/gtk-3.0
│ │  -rw-r--r-- root/root               890 2017-03-24 01:27 /etc/gtk-3.0/im-multipress.conf
│ │  -rw-r--r-- root/root              4781 2017-01-24 11:20 /etc/hdparm.conf
│ │  -rw-r--r-- root/root                 9 2006-08-07 17:14 /etc/host.conf
│ │ --rw-r--r-- root/root                22 2017-08-05 13:25 /etc/hostname
│ │ +-rwxr-xr-x root/root                22 2017-08-05 13:25 /etc/hostname
│ │  -rw-r--r-- root/root                 0 2017-08-05 13:25 /etc/hosts
│ │  -rw-r--r-- root/root               411 2017-08-05 13:25 /etc/hosts.allow
│ │  -rw-r--r-- root/root               711 2017-08-05 13:25 /etc/hosts.deny
│ │  drwxr-xr-x root/root                33 2017-08-05 13:25 /etc/hp
│ │  -rw-r--r-- root/root               961 2017-08-05 13:25 /etc/hp/hplip.conf
│ │  drwxr-xr-x root/root                31 2017-08-05 13:25 /etc/ifplugd
│ │  drwxr-xr-x root/root                33 2017-08-05 13:25 /etc/ifplugd/action.d

Files

diffoscope-nock@nocko.se.txt (1486 B) anonym, 2017-08-15 09:28:24

Subtasks

History

#1 Updated by intrigeri 2017-08-13 16:11:26

#2 Updated by intrigeri 2017-08-13 16:13:42

Wow, that’s weird! Anyway, I think we configure hostname at boot time via live-config, so we could perhaps simply not ship this file in the SquashFS at all. Not sure what the implications would be for early boot stuff run before live-config though.

#3 Updated by anonym 2017-08-13 16:26:07

/etc/hostname is generated by live-build via lb_chroot_hostname and it’s this one-liner:

echo "localhost.localdomain" > chroot/etc/hostname


Note that the umask cannot be the cause. What could be?

lamby: I added you as a watcher, but for now I think we’ll have you prioritize the other reproducibility tickets, ok?

#4 Updated by anonym 2017-08-13 16:26:23

#5 Updated by intrigeri 2017-08-13 16:55:38

> Note that the umask cannot be the cause. What could be?

Given we can trivially chmod this before building the SquashFS, I suggest we just do that and don’t bother about investigating deeper until we notice other, similar issues that might share the same root cause.

#6 Updated by lamby 2017-08-13 17:16:47

intrigeri wrote:
> don’t bother about investigating deeper until we notice other, similar issues that might share the same root cause.

I agree.

(Can you clarify why it 100% cannot be umask?)

#7 Updated by lamby 2017-08-13 17:17:49

(Can the diffoscope output be added here? Whilst you link to the ML post, the attachment has been scrubbed for some reason…)

#8 Updated by anonym 2017-08-15 09:55:06

  • File diffoscope-nock@nocko.se.txt added
  • Status changed from Confirmed to In Progress
  • Assignee changed from anonym to intrigeri
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/13623-reproducible-etc-hostname-permissions
  • Type of work changed from Research to Code

lamby wrote:
> intrigeri wrote:
> > don’t bother about investigating deeper until we notice other, similar issues that might share the same root cause.
>
> I agree.

Ok!

I’ve pushed a branch with the proposed solution. I went with chmod u=rw,go=r instead of chmod a-x since I don’t see why we would be any more interested in any of the other bits flipping. Let me know if you think otherwise!

intrigeri, please review’n’merge into devel!

> (Can you clarify why it 100% cannot be umask?)

Let’s assume that files are created with perms 666 by default before applying the umask. Then we need an umask X such that 666 & ~X = 755. 666 has all of the executable bits set to 0, but there’s no way we can AND 0 with something to get 1, which is the case for all the executable bits of 755, so there’s no such X. QED.

However, my reasoning completely depends on the assumption that files are always created with perms 666 (before the umask is applied). This is some sort of standard, but I just realized that there’s nothing enforcing this, so it’s up to each application to be sensible about permissions. So I’m wrong — some crappy application could have created the file with perms 777 which with our umask of 022 indeed would become 755. In our case the file is created via shell IO redirection (unless something else happens with the file afterwards), so I suppose the “crappy application” then should be dash… which I’ve never seen misbehave in this way. Hrm.

> (Can the diffoscope output be added here? Whilst you link to the ML post, the attachment has been scrubbed for some reason…)

Attached!

#9 Updated by intrigeri 2017-08-19 13:55:46

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

Applied in changeset commit:95fbb971228f6b44cbb71d116c444d501541b3af.

#10 Updated by intrigeri 2017-08-19 13:56:36

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#11 Updated by anonym 2017-09-28 18:50:09

  • Status changed from Fix committed to Resolved