Bug #16383

3.12~rc fails to configure printers

Added by Anonymous 2019-01-22 12:27:44 . Updated 2019-01-30 11:59:47 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Hardware support
Target version:
Tails_3.13
Start date:
2019-01-22
Due date:
% Done:

100%

Feature Branch:
bugfix/16383-printer-config+force-all-tests
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

There were two reports on tails-testers that said that thy cannot install their network printers anymore:


3.12RC detects my network connected Brother HL2070N, but "printer installation" fails. 

3.12RC does *not* detect my UBS connected HL2070N printer. The detection process/step appears not to happen/is not initiated.

ALL Tails versions prior to 3.12RC have both detected and successfully "installed" this printer.

Files

tails-amd64-bugfix_16383-printer-config+force-all-tests-3.12-20190124T2023Z-7dd2850e7a.buildlog.xz (110116 B) lamby, 2019-01-24 22:52:56

Subtasks

Related issues

Blocks Tails - Feature #15507: Core work 2019Q1: Foundations Team Resolved 2018-04-08

History

#1 Updated by Anonymous 2019-01-22 12:30:32

  • Subject changed from 3.12 fails to install network printers to 3.12~rc fails to install network printers

#2 Updated by intrigeri 2019-01-23 16:32:39

  • Subject changed from 3.12~rc fails to install network printers to 3.12~rc fails to configure Brother HL2070N printers
  • Category set to Hardware support

(This affects that printer when connected via USB too. We don’t know yet if this affects any other printer.)

Thanks. I’ll test with a printer I have access to.

Help desk, please let me know if this sort of regression is reported.

#3 Updated by intrigeri 2019-01-23 16:40:22

  • Subject changed from 3.12~rc fails to configure Brother HL2070N printers to 3.12~rc fails to configure printers
  • Assignee set to intrigeri

Reproduced with a HP network printer. I’ll investigate the errors I see in the logs.

#4 Updated by intrigeri 2019-01-23 16:54:02

Relevant logs:

Jan 23 16:49:40 amnesia dbus[1141]: [system] Activating service name='org.opensuse.CupsPkHelper.Mechanism' (using servicehelper)
Jan 23 16:49:40 amnesia dbus[9520]: [system] Failed to reset fd limit before activating service: org.freedesktop.DBus.Error.AccessDenied: Failed to restore old fd limit: Operation not permitted
Jan 23 16:49:40 amnesia dbus[1141]: [system] Activated service 'org.opensuse.CupsPkHelper.Mechanism' failed: The permission of the setuid helper is not correct
Jan 23 16:49:40 amnesia gnome-control-c[9471]: GDBus.Error:org.freedesktop.DBus.Error.Spawn.PermissionsInvalid: The permission of the setuid helper is not correct
Jan 23 16:49:40 amnesia gnome-control-c[9471]: Installation of the new printer failed.

#5 Updated by intrigeri 2019-01-23 17:13:12

On Tails 3.11, /usr/lib/dbus-1.0/dbus-daemon-launch-helper is setuid root. On 3.12~rc1 it’s not but making it setuid root fixes this regression.

#6 Updated by intrigeri 2019-01-23 18:01:57

These permissions are normally set via dpkg-statoverride in dbus.postinst. I suspect one of our build hooks breaks this, debugging.

#7 Updated by intrigeri 2019-01-23 18:25:24

Before Changing GID for messagebus (109 -> 1050) the permissions are correct: -rwsr-xr--. But after that they’re broken: -rwxr-xr--.

#8 Updated by intrigeri 2019-01-23 18:33:47

  • Status changed from Confirmed to In Progress

chown() clears setuid, setgid, and possibly also capabilities and ACLs. So we need to do something a bit more elaborate to ensure we don’t lose them along the way. More info and implementation ideas:

#9 Updated by intrigeri 2019-01-24 09:36:40

#10 Updated by intrigeri 2019-01-24 16:20:51

The storage stack that backs our / supports neither extended attributes (getfattr/setfattr), nor Linux filesystem attributes (lsattr/chattr), nor file capabilities (getcap/setcap), nor ACLs. On the one hand it’s too bad, e.g. the lack of support for capabilities is the reason why /bin/ping is setuid root on Tails but not on the average Debian system. OTOH it’ll make it vastly easier to fix this bug: the only thing we need to restore is basic DAC permissions (chmod).

#11 Updated by intrigeri 2019-01-24 17:11:59

  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/16383-printer-config+force-all-tests

#12 Updated by intrigeri 2019-01-24 17:33:40

  • Assignee changed from intrigeri to lamby
  • QA Check set to Ready for QA

Built an ISO, confirmed the permissions of /usr/lib/dbus-1.0/dbus-daemon-launch-helper are fixed, verified that I can configure a printer. Verified that the list of setuid and/or setgid executables did not suddenly become huge. Please do a code review, optionally some of these tests and/or other checks you can think of. I’m happy to check the CI results myself.

Thanks!

#13 Updated by lamby 2019-01-24 23:07:18

[Not marking as QA complete, see below]

Methodology:

  • Checked out bugfix/16383-printer-config+force-all-tests at 7dd2850e7a084911c0d71a6211b6eba561148b12 (“Preserve setuid & setgid bits when giving files back to their renumbered owner (refs: Bug #16383)”)
  • Built. See attached tails-amd64-bugfix_16383-printer-config+force-all-tests-3.12-20190124T2023Z-7dd2850e7a.buildlog.xz
  • Booted image in qemu, adding administration password

  • Confirming setuid root bit now set:

… but I don’t see aetgid, so you get:

Is this actually a problem?

#14 Updated by intrigeri 2019-01-25 07:46:55

Across 2 full test suite runs on Jenkins, every scenario passed at least once except:

  • “MAC address spoofing fails and the module is not removed”: notification not seen, known issue; thanks to commit:26671c6e2c6361a12d284f0e95cdc78ecce9c146 at least we know that the safety-critical properties are satisfied
  • “Watching a WebM video over HTTPS”: always fails on Jenkins these days, not sure why (Bug #10442)

#15 Updated by intrigeri 2019-01-25 07:53:43

  • Assignee changed from intrigeri to lamby

> * Confirming setuid root bit now set:
> … but I don’t see aetgid, so you get:

> Is this actually a problem?

/var/lib/dpkg/info/dbus.postinst sets permissions on this file to 4754, i.e. what you’ve observed. I see the same permissions on Tails 3.11 and on my sid system so everything seems to be in order.

The fact the amnesia user cannot execute this program has nothing to do with the setgid bit: instead, it’s because amnesia not in the messagebus group and the executable bit is not set for “others”. That’s on purpose: only members of the messagebus group, i.e. the messagebus user, are meant to benefit from the setuid root property (so the system-wide D-Bus daemon can start this helper as root).

#16 Updated by lamby 2019-01-25 08:26:21

  • Assignee changed from lamby to intrigeri
  • QA Check changed from Ready for QA to Pass

> the system-wide D-Bus daemon can start this helper as root

Getcha. I assumed it was per-user and/or amnesia needed to part of that group. :) Marking as QA pass and returning to you.

#17 Updated by intrigeri 2019-01-25 08:53:17

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

Applied in changeset commit:tails|8b8755d70e51f7fc61a2667784a94923514abb45.

#18 Updated by intrigeri 2019-01-25 08:54:15

  • Assignee deleted (intrigeri)

Thanks!

#19 Updated by anonym 2019-01-30 11:58:12

  • Status changed from Fix committed to Resolved

#20 Updated by anonym 2019-01-30 11:59:39

  • Target version changed from Tails_3.12 to Tails_3.13