Tails

#1 Updated by anonym 2015-09-01 04:04:03

• Assignee set to intrigeri
• Target version set to Tails_1.6
• QA Check set to Dev Needed

It definitely seems AppArmor-related; iIf I disable AppArmor it works. This is what’s logged when AppArmor is enabled and the error triggers:

audit: type=1400 audit(1441103843.476:24): apparmor="DENIED" operation="open" profile="/usr/local/lib/tor-browser/firefox" name="/etc/default/nss" pid=5495 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

intrigeri, will you have a look?

#2 Updated by intrigeri 2015-09-01 04:44:22

• Assignee changed from intrigeri to emmapeel
• QA Check changed from Dev Needed to Info Needed

> Maybe AppArmor?

Maybe. Please check that in the output of sudo dmesg | grep apparmor | grep DENIED.

(Meta: sure, I could check myself, but at this stage it’s not clear yet if that’s on my plate (because AppArmor) or on anonym’s (because TBB 5.0). I don’t expect frontdesk to suddenly become experts at AppArmor stuff, but it would be awesome if you folks learnt to quickly check in the logs if AppArmor has actually denied anything. We would save quite a few back’n’forth, and it would make it easier to know at first glance which developer shall spend time looking into it deeper :)

#3 Updated by emmapeel 2015-09-01 04:50:28

• Assignee changed from emmapeel to intrigeri

intrigeri wrote:
> > Maybe AppArmor?
>
> Maybe. Please check that in the output of sudo dmesg | grep apparmor | grep DENIED.
>
Cool, I will take it into account in the future. It produces an error:

[ 5985.260396] audit: type=1400 audit(1441108052.744:26): apparmor="DENIED" operation="open" profile="/usr/local/lib/tor-browser/firefox" name="/etc/default/nss" pid=28384 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

> (Meta: sure, I could check myself, but at this stage it’s not clear yet if that’s on my plate (because AppArmor) or on anonym’s (because TBB 5.0). I don’t expect frontdesk to suddenly become experts at AppArmor stuff, but it would be awesome if you folks learnt to quickly check in the logs if AppArmor has actually denied anything. We would save quite a few back’n’forth, and it would make it easier to know at first glance which developer shall spend time looking into it deeper :)

I think anonym already reviewed it for this specific bug. Should I do anything else?

#6 Updated by intrigeri 2015-09-01 06:07:10

• QA Check deleted (Info Needed)

#7 Updated by intrigeri 2015-09-17 01:22:30

• related to Bug #9558: Tor Browser confinement allows downloading to /tmp added

#9 Updated by intrigeri 2015-09-17 01:30:56

• Status changed from Confirmed to In Progress
• % Done changed from 0 to 10

#11 Updated by intrigeri 2015-09-17 02:27:44

• Target version changed from Tails_1.6 to Tails_1.7

We’ll see what upstream says. I’ll come back to it during the 1.7 cycle.

#12 Updated by intrigeri 2015-11-01 05:53:34

• Target version changed from Tails_1.7 to Tails_1.8
• Type of work changed from Code to End-user documentation

No answer from Mozilla. I spent some time grep’ing the Firefox source code and could not find where this /tmp path is set; perhaps it’s set in some external library that Firefox uses for generating the print preview.

Sadly, we don’t have many exciting options:

a) Simply revert the changes introduced to fix Bug #9558. Given Bug #9949#note-12, this would be even more dangerous than what we thought when we fixed Bug #9558 in the first place, and thus sounds like a pretty bad idea.

b) Fix the problem mentioned in Bug #9949#note-12 and then revert the changes introduced to fix Bug #9558, so we’re back to being affected by Bug #9558.

c) Pull some more strings for having this fixed upstream (Tor Browser people could be interested as well). I could do one more step in this direction.

d) Implement some Tails -specific workaround (e.g. with namespaces + bind-mounts to give Tor Browser an empty /tmp/ modulo the files it needs). And then maintain it possibly forever. No, thanks.

Of course it’s a matter of setting some cursor at the right place, so here’s some extremely basic and fully biased analysis of the UX impact. Bug #9558 was fixed in 1.5, so the regression this ticket is about was introduced in 1.5, but it was reported to us only 3 weeks later, which is an indicator that it was not an important problem affecting many of our users. There’s also a existing workaround (print to file and view the file), which sure is a bit painful, but one can still preview before printing if really needed.

So all in all, I personally think that this UX regression is too minor to be worth fixing in a way that either introduces important security regressions (a, b), or that takes us a lot of time (d). I’m sure our limited developer resources can be better used elsewhere to improve Tails UX. My plan is then to do ©, add this problem to the known issues page with its workaround (“sorry, no print preview due to Mozilla bug XXX combined with the fact that we want to give you a not ridiculously scary way to use a web browser; do that instead”), and close this ticket.

#13 Updated by intrigeri 2015-11-02 03:07:09

• % Done changed from 10 to 20

intrigeri wrote:
> c) Pull some more strings for having this fixed upstream (Tor Browser people could be interested as well). I could do one more step in this direction.

Asked TBB team for their gut feeling and advice.

#14 Updated by intrigeri 2015-12-14 09:37:57

• Subject changed from TBB 'Print preview' don't show contents of page (although can still print the page ok) to Document how to workaround the fact that the TBB 'Print preview' is blank
• Target version changed from Tails_1.8 to Tails_2.0

intrigeri wrote:
> My plan is then to do ©,

No reply on the upstream bug since 3 months.

> add this problem to the known issues page with its workaround (“sorry, no print preview due to Mozilla bug XXX combined with the fact that we want to give you a not ridiculously scary way to use a web browser; do that instead”), and close this ticket.

I’ll do that then.

#15 Updated by intrigeri 2015-12-14 15:59:48

• Feature Branch set to doc/10141-print-preview

#16 Updated by intrigeri 2015-12-14 16:07:42

• Assignee changed from intrigeri to sajolida
• % Done changed from 20 to 30
• QA Check set to Ready for QA

sajolida, do you want to take this one?

Spoiler: it’s just rough hinting the user, and lack all kinds of details and step-by-step instructions. Good enough?

#17 Updated by sajolida 2016-01-15 19:24:17

• Status changed from In Progress to Resolved
• % Done changed from 30 to 100

Applied in changeset commit:d64d7b9524ea52dc5a2614aed44a090ab2e879ae.

#18 Updated by sajolida 2016-01-15 19:25:18

• Assignee deleted (sajolida)
• % Done changed from 100 to 30
• QA Check deleted (Ready for QA)

#19 Updated by intrigeri 2016-01-15 21:15:19

• % Done changed from 30 to 100