Bug #8917

Spurious "permission denied" error when trying to upload files from Tor Browser

Added by goupille 2015-02-18 22:13:18 . Updated 2017-09-28 18:49:13 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_3.2
Start date:
2015-02-18
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Browser
Deliverable for:

Description

it is no more possible to print a webpage to a pdf file with torbrowser due to a permission error

to reproduce it, open torbrowser, go to any page, ctrl-p, choose “print in a file”
an error occurs “permission denied” unable to read the content of amnesia.

this issue wasn’t there in 1.2.3

Files

Screen Shot 2015-02-27 at 11.34.40 AM.png (492363 B) garrettr, 2015-02-27 16:38:39
Screen Shot 2015-02-27 at 11.36.24 AM.png (451162 B) garrettr, 2015-02-27 16:38:58
Screen Shot 2015-02-27 at 3.51.53 PM.png (384761 B) garrettr, 2015-02-27 20:52:46
fix_default_firefox_directory.png (89031 B) garrettr, 2015-08-14 16:22:41

Subtasks

Related issues

Related to Tails - Bug #8916: Torbrowser spellchecking doesn't work in 1.3-rc1 Resolved 2015-02-18
Has duplicate Tails - Bug #9334: Tor Browser defaults to a restricted folder for uploads Duplicate 2015-05-03
Blocked by Tails - Feature #12115: Migrate to Tor Browser based on FF52 Resolved 2015-02-18
Blocks Tails - Feature #13234: Core work 2017Q3: Foundations Team Resolved 2017-06-29

History

#1 Updated by BitingBird 2015-02-18 22:36:24

  • Subject changed from torbrowser is unable to print-to-pdf in 1.2.3~rc1 to Torbrowser is unable to print-to-pdf in 1.2.3~rc1
  • Affected tool set to Browser

Probably has to do with AppArmor, too.

#2 Updated by BitingBird 2015-02-18 22:36:48

  • related to Bug #8916: Torbrowser spellchecking doesn't work in 1.3-rc1 added

#3 Updated by intrigeri 2015-02-18 22:46:50

  • Subject changed from Torbrowser is unable to print-to-pdf in 1.2.3~rc1 to Torbrowser is unable to print-to-pdf in 1.3~rc1
  • Status changed from Confirmed to New
  • Assignee set to goupille
  • QA Check set to Info Needed

That message is expected, and I wasn’t able to get rid of it. But you should be able to print to PDF to one of the allowed directories, as documented. No?

(I mean, I wrote an automated test to make sure it works, so I’d be surprised if it was suddenly broken)

#4 Updated by intrigeri 2015-02-18 22:54:19

  • Target version set to Tails_1.3

#5 Updated by goupille 2015-02-18 23:17:43

  • Subject changed from Torbrowser is unable to print-to-pdf in 1.3~rc1 to "permission denied" error when trying to print-to-pdf with Tor Browser in 1.3~rc1

actually, if you just ignore the error message and select the dedicated directory, it works well…

#6 Updated by intrigeri 2015-02-19 00:14:27

  • Subject changed from "permission denied" error when trying to print-to-pdf with Tor Browser in 1.3~rc1 to Spurious "permission denied" error when trying to print to PDF from Tor Browser
  • Status changed from New to Confirmed
  • Assignee deleted (goupille)
  • Target version deleted (Tails_1.3)
  • QA Check deleted (Info Needed)

This issue was known before merging: the automated test suite actually clicks through this error dialog. It was deemed acceptable and merged this way. I’ve looked for ways to set the default “Print to file” output directory, and failed. If users/frontdesk go mad because of it after 1.3 is out, I can try again. Otherwise, I guess we’ll have to live with it until someone comes up with magical old runes and teaches me how to fix it. I guess one would have to read the code to know.

#7 Updated by garrettr 2015-02-24 15:28:29

This issue also occurs when opening a “File Upload” dialog box (e.g. by clicking the “Browse…” button next to an <input type=file> to open the file picker).

Unfortunately, there is no easy way to resolve this issue. Firefox associates the last directories used for upload/download with each origin, using the nsIContentPrefService2. That means that one the user has successfully upload a file from (or downloaded a file to) the Tor Browser directory, it will be remembered for the remainder of the session. However, since the Tor Browser intentionally avoids persisting this type of state across restarts, users will still encounter this spurious warning message often.

Unfortunately, there is no way to change the default directory that is used if no directory is associated with the current domain. It is hard-coded to be the OS’ Desktop folder.

I would argue that this is a severe usability issue for the average user, and should be fixed before the 1.3 release. It is confusing, is likely to appear multiple times (per Tor Browser session), and might be alarming or frightening.

There are two general ways to fix this issue:

  1. Patch Firefox/Tor Browser to make the default directory customizable, e.g. via a pref in about:config. Then Tails can modify that pref to be the whitelisted “Tor Browser” directory.
  2. Since the Desktop folder is the default, whitelist it as well.

I think the first solution is ideal, but would take some time to implement. I can write the patch for Firefox, but then we would have to either:

  1. Maintain a Tails-specific fork of Tor Browser with this custom patch (I’m not sure if you already maintain your own fork or not)
  2. Get the Tor Browser team to take the patch
  3. Get Mozilla to take the patch

I am happy to work on any of these approaches, but must admit that the first will take time and effort and the second two will take a significant amount of time (we’ll have to wait for their release cycle, assuming they even agree to take the patch).

I think the second solution (whitelist the Desktop folder) is a good compromise, at least for 1.3. People often use the Desktop folder as a temporary space for uploads/downloads anyway. I also do not think it is much of a security risk (compared to, say, whitelisting the Home directory). It will get rid of this annoying error message in Tor Browser. And it is easy - just one line of AppArmor config.

I would advocate for whitelisting the Desktop folder for 1.3, and then working on one of the approaches listed above to make it possible to customize the default directory in Tor Browser. In a future release, we could return to the most restrictive set of rules (Tor Browser directory only), once we are able to indicate that Tor Browser should default to that location.

#8 Updated by intrigeri 2015-02-27 11:00:44

  • Subject changed from Spurious "permission denied" error when trying to print to PDF from Tor Browser to Spurious "permission denied" error when trying to upload files or to print to PDF from Tor Browser
  • Status changed from Confirmed to In Progress
  • Target version set to Tails_1.3.2
  • % Done changed from 0 to 10

garrettr wrote:
> This issue also occurs when opening a “File Upload” dialog box […].

OK, so it’s worse than I thought. Thanks. Adjusting priority, and tentatively flagging for 1.3.1, then.

> Unfortunately, there is no way to change the default directory that is used if no directory is associated with the current domain. It is hard-coded to be the OS’ Desktop folder.

Thanks a lot for doing all this research! Now, I’m unsure about the conclusion: apparently the default value for NS_OS_DESKTOP_DIR is indeed hardcoded, but to the Desk string. In our case the value being used is Desktop, right? So it must be retrieved from somewhere else by NS_GetSpecialDirectory. I suspected that the actually used value would come from the XDG directory configuration being used, so I grep’d the Tor Browser source tree for “DESKTOP” and “XDG”, and then indeed there are references to the XDG Desktop directory. So I suspect we could:

  • run Tor Browser with a custom XDG_CONFIG_HOME environment variable set, that would point to somewhere else than the default
  • add a custom user-dirs.dirs file in the directory where the custom XDG_CONFIG_HOME points to
  • in that custom user-dirs.dirs, set XDG_DESKTOP_DIR to point to ~/Tor Browser

I guess this would just work as far as the default upload and print-to-PDF directories are concerned. Now, I wonder what else we would be breaking: perhaps Tor Browser uses XDG_CONFIG_HOME for unrelated things, e.g. to know where the config is to talk to tools used behind the curtain, such as PulseAudio or GStreamer.

garrettr: do you want to give it a try, and test various things that might be affected by a different XDG_CONFIG_HOME value? Any modern piece of software that 1. cares a bit about FreeDesktop.org standards; 2. could be used by Tor Browser — may be affected, I assume. If you try this out, please report back exactly what you tested, and then I’ll look into the AppArmor profiles for more candidates for testing.

#9 Updated by intrigeri 2015-02-27 11:02:59

  • Assignee set to garrettr
  • QA Check set to Info Needed

garrettr: see previous comment in case you missed it. (I just added you as a watcher on this ticket, so that you get a notification by Redmine.)

#10 Updated by garrettr 2015-02-27 16:39:51

intrigeri wrote:
> So I suspect we could:
>
> * run Tor Browser with a custom XDG_CONFIG_HOME environment variable set, that would point to somewhere else than the default
> * add a custom user-dirs.dirs file in the directory where the custom XDG_CONFIG_HOME points to
> * in that custom user-dirs.dirs, set XDG_DESKTOP_DIR to point to ~/Tor Browser

I got started by testing to see if we could indeed achieve the desired behavior by changing XDG_DESKTOP_DIR to point to ~/Tor Browser.

  1. Booted Tails 1.3
  2. Created ~/.config/user-dirs.dirs (I’m leaving XDG_CONFIG_HOME unchanged for now)
  3. I filled in the defaults from the ArchLinux wiki and changed XDG_DESKTOP_DIR="$HOME/Desktop" to XDG_DESKTOP_DIR="$HOME/Tor Browser".
  4. Started Tor Browser, navigated to tinyupload.com, and clicked the “Browse…” button to reproduce the issue.

This sort of works. The default directory for uploads is indeed changed to “Tor Browser”. Unfortunately, “Tor Browser” is no longer present in the sidebar, and “Desktop” is still selected in the sidebar, even though the path at the top shows “Tor Browser” is the directory. See attached screenshots.

So the hack works, but it’s also somewhat confusing. It would be better if the “Tor Browser” directory was in the sidebar, and was selected by default in the dialog. Since users only have two directories in the home directory by default, Desktop and Tor Browser, having them to overlap in this way is (IMO) likely to be confusing.

#11 Updated by intrigeri 2015-02-27 18:36:17

garrettr wrote:
> I got started by testing to see if we could indeed achieve the desired behavior by changing XDG_DESKTOP_DIR to point to ~/Tor Browser.

Excellent!

> This sort of works. The default directory for uploads is indeed changed to “Tor Browser”. Unfortunately, “Tor Browser” is no longer present in the sidebar, and “Desktop” is still selected in the sidebar, even though the path at the top shows “Tor Browser” is the directory. See attached screenshots.

I bet that “Desktop” directory in the sidebar points to ~/Tor Browser, and the two entries are simply deduplicated since they now point to the same place. What happens if you do the same but modify ~/.gtk-bookmarks this way:

  • find the line that says something like file:///home/amnesia/Tor%20Browser
  • at the end of this line, add " Tor Browser" (without the quotes, but with the leading space)

I wonder if GTK will deduplicate the two entries in this case, given we’re explicitly giving one of those a different name.

> So the hack works, but it’s also somewhat confusing. It would be better if the “Tor Browser” directory was in the sidebar, and was selected by default in the dialog.

Agreed.

#12 Updated by garrettr 2015-02-27 20:53:08

intrigeri wrote:
> I bet that “Desktop” directory in the sidebar points to ~/Tor Browser, and the two entries are simply deduplicated since they now point to the same place. What happens if you do the same but modify ~/.gtk-bookmarks this way:
>
> * find the line that says something like file:///home/amnesia/Tor%20Browser
> * at the end of this line, add " Tor Browser" (without the quotes, but with the leading space)
>
> I wonder if GTK will deduplicate the two entries in this case, given we’re explicitly giving one of those a different name.

I tried this and it did not work. An additional entry for Tor Browser was not created. I tried adding both a leading space and a trailing space. These changed names appear in the “Places” menu but not in the “File Upload” dialog box. I think the de-duplication in that box is based on the path, not the name. It also appears to be based on the resolved path, since I tried some trickery e.g. file:///home/amnesia/Tor%20Browser/../Tor%20Browser without success. Multiple entries in ~/.gtk-bookmarks were all collapsed into one as long as their paths resolved to the same path.

Additionally, the change in user-dirs.dirs leads to inconsistent and confusing resolution of the “Desktop” directory elsewhere. For example, with that change:

1. Double-click the “home” directory on the desktop, then click “Desktop” in the sidebar. You end up in “Tor Browser” (see screenshot).
2. Click the “Places” menu, then click “Desktop”. You end up in “Desktop”.

Again, I think the core issue with this workaround is the confusing conflation of the “Desktop” shortcut and the “Tor Browser” directory, especially because the “Tor Browser” directory is not the actual desktop, and there is a separate “Desktop” directory.

I still think the best solution here is the one I proposed in #7:

1. Whitelist $HOME/Desktop in the Tor Browser AppArmor rules for Tails 1.3.1
2. Work on a patch to customize this in Firefox, and get it merged somewhere upstream. Once that is done, we can totally restrict downloads/uploads to the “Tor Browser” directory in a follow-up issue.

#13 Updated by intrigeri 2015-02-27 21:38:26

> I tried this and it did not work. An additional entry for Tor Browser was not created.

Too bad :( But thanks for trying! Your contribution to this ticket so far has been invaluable.

> I think the de-duplication in that box is based on the path, not the name.

Makes sense. So probably a symlink trick wouldn’t work either. Maybe bind-mounts (possibly within a dedicated mount namespace) would do the trick, but I didn’t think of it much yet, and perhaps it’s not worth spending too much time on this hypothesis of mine.

> Additionally, the change in user-dirs.dirs leads to inconsistent and confusing resolution of the “Desktop” directory elsewhere.

Sure. The good news is: the idea was to give a custom XDG_CONFIG_HOME to Tor Browser only, though, so the following example breakage actually don’t matter :)

> I still think the best solution here is the one I proposed in #7:

> 1. Whitelist $HOME/Desktop in the Tor Browser AppArmor rules for Tails 1.3.1

If it was a short-term fix only, I could easily be convinced that it’s not a big deal. However:

  • Even once we have a patch written and merged in Firefox (your point below), we’ll need to wait for the next ESR release (2016Q1 iirc) to have it, so it can very well be that this item stays on our whitelist for one more year.
  • Many desktop environment users use the Desktop as a place to dump random stuff temporarily. Exposing such random stuff to an exploited browser would be quite inconsistent with what we’re trying to achieve with this AppArmor confining in the first place.

That’s why I’m not looking at this possibility with uncontrollable enthusiasm. As often in Tails, we have to make a compromise between UX and security here. Generally I would advocate for UX, but in this case I’m not convinced it’s the way to go, and of course we still lack actual data regarding how bad the new UX is in practice.

A good way to get useful data would be to ask our frontdesk (tails-support-private@boum.org) and people doing lots of user support on IRC (BitingBird) how many problems they see reported about it in the next few weeks. And then, we’ll be in a better position to make a decision. Do you want to ask them to keep an eye on this and report back in a few weeks?

> 2. Work on a patch to customize this in Firefox, and get it merged somewhere upstream. Once that is done, we can totally restrict downloads/uploads to the “Tor Browser” directory in a follow-up issue.

I agree that’s the best mid-term solution (long-term, hopefully we’ll have a better solution: GTK file chooser + privileged backend, which is WIP by AppArmor team IIRC).

I guess it might make sense to upstream, since they already have a pref to configure the default download directory. If you’re still interested in working on it, next step is probably to look in Mozilla’s bugzilla if there’s already a ticket about it. Are you on it? I certainly hope so :)

#14 Updated by intrigeri 2015-03-19 18:22:53

Ping?

#15 Updated by BitingBird 2015-04-01 12:42:16

  • Target version changed from Tails_1.3.2 to Tails_1.4

#16 Updated by intrigeri 2015-04-25 05:51:17

Pinged Garrett over private email.

#17 Updated by intrigeri 2015-05-04 01:00:57

  • has duplicate Bug #9334: Tor Browser defaults to a restricted folder for uploads added

#18 Updated by BitingBird 2015-05-09 03:37:50

I can report that despite the doc, I see this issue reported once a day on average on irc (when I’m there).

#19 Updated by BitingBird 2015-05-09 03:42:02

  • Target version changed from Tails_1.4 to Tails_1.4.1

Postponing

#20 Updated by intrigeri 2015-07-03 01:01:13

  • Target version changed from Tails_1.4.1 to Tails_1.5

#21 Updated by intrigeri 2015-08-09 00:24:25

  • Assignee changed from garrettr to intrigeri
  • Target version changed from Tails_1.5 to Tails_1.6
  • QA Check deleted (Info Needed)

OK, seems like Garrett won’t have time to handle it. For 1.6 I’ll try to sum up the current state of the discussion, to check upstream bug tracker if needed, and perhaps to come up with a proposal to them.

#22 Updated by garrettr 2015-08-14 15:44:19

  • Assignee changed from intrigeri to garrettr

(Let me know if it’s poor etiquette for me to re-assign the bug to myself, and I will refrain from doing so in the future).

Sorry for dropping this issue for a while. I’m still interested in helping to resolve it, since it’s an annoying UX issue for SecureDrop users.

I examined the Mozilla bug tracker and couldn’t find any issues related to allowing customization of the default file picker directory, so I filed one: https://bugzilla.mozilla.org/show_bug.cgi?id=1194893.

I’m not sure if the Mozilla devs will be enthusiastic to add code in order to work around a downstream bug, but I explained the situation in the bug so it is their call. The fix would be pretty simple, so hopefully they’ll be ok with it anyway. If not, we’ll need to try getting this merged into Tor Browser next, or create a Tails fork of Tor Browser.

I’ve got a Firefox development environment set up again, so I’ll start working on a patch for this (although it is still a low priority for me).

#23 Updated by garrettr 2015-08-14 16:23:32

Ok, now I feel foolish. I decided to re-visit some of intrigeri’s proposed workarounds from earlier in the thread to see if we could find a more lightweight solution. One of them was to create a Tor-Browser-specific XDG_DESKTOP_DIR to change the default desktop directory.

I’d already tried XDG_DESKTOP_DIR="$HOME/Tor Browser", which sort of worked but created a confusing mismatch between the directory and the selected entry in the “Places” menu on the left side of the file picker. See Comment #10 for details.

I tried it again, but this time I set the line in ~/.config/user-dirs.dirs to

XDG_DESKTOP_DIR="$HOME/Tor Browser" "Tor Browser"

This works!!! See attached screenshot.

Unfortunately, I can’t explain why this works. It isn’t mentioned as a feature in any of the documentation for user-dirs that I’ve looked at, such as the user-dirs.dirs man page.

If anybody understands XDG better than me, I’d love to understand why this is working. Either way, I think we should move forward with a fix based on this discovery.

#24 Updated by intrigeri 2015-08-18 05:07:00

> (Let me know if it’s poor etiquette for me to re-assign the bug to myself, and I will refrain from doing so in the future).

That’s totally fine.

I’ll look at your updates on this ticket later, hopefully by the end of the month.

#25 Updated by intrigeri 2015-08-25 02:00:43

garrettr wrote:
> I examined the Mozilla bug tracker and couldn’t find any issues related to allowing customization of the default file picker directory, so I filed one: https://bugzilla.mozilla.org/show_bug.cgi?id=1194893.

I see they’re asking to see a patch.

#26 Updated by intrigeri 2015-08-25 02:36:15

Thanks! I’ve tried this:

mkdir -p ~/.tor-browser/home/.config
echo 'XDG_DESKTOP_DIR="$HOME/Tor Browser" "Tor Browser"' \
  > ~/.tor-browser/home/.config/user-dirs.dirs
# add to the torbrowser AppArmor profile, then reload it:
# owner @{HOME}/.tor-browser/home/.config/user-dirs.dirs r,
export XDG_CONFIG_HOME=/home/amnesia/.tor-browser/home/.config
tor-browser

Results:

  • the “File -> Open file” dialog looks good (no Desktop in the sidebar, no error message, “Tor Browser” is listed in the sidebar); same for the upload file dialog, that defaults to “Tor Browser”
  • “Print to file” still defaults to /home/amnesia, and thus is still broken. What can we do about it?
  • At least HTML5 audio+video playback (PulseAudio) is not broken by the custom XDG_CONFIG_HOME.
  • I see in the AppArmor logs that Firefox tries to access /home/amnesia/.tor-browser/home/.config/ibus/, which confirms that setting XDG_CONFIG_HOME has a broader impact. I’ve not checked if IBus works anyway or not. Next steps on this aspect:
    • Test IBus
    • If IBus broken, add symlinks from ~/.tor-browser/home/.config/... to the corresponding file in $HOME, add corresponding AppArmor permissions if needed, etc., until it’s repaired.
    • Test various other stuff that could be affected by XDG_CONFIG_HOME, keeping an eye on the AppArmor logs (that are pretty helpful to identify what files Tor Browser newly tries to access).

#27 Updated by garrettr 2015-08-28 16:03:25

intrigeri wrote:
> I see they’re asking to see a patch.

I wrote a patch this week and got it r+’ed, so it should be ready to land. I am working on getting my Mozilla commit access re-instated so I can run it against their test suite (a prerequisite for landing).

Note that even once the patch is landed, it will probably be a while before it can be used in Tails. The next Firefox ESR, which is what Tor Browser is based on, will be Firefox 45 and won’t be released until March 2016.

On the other hand, the patch I wrote is pretty small and affects code that doesn’t get changed much, so if Tails wanted to maintain a temporary fork of Tor Browser with this patch available (until Firefox 45 comes out and Tor Browser upgrades to be based off of it) that should be fairly easy to do, at least in terms of keeping the patch from bit-rotting.

#28 Updated by intrigeri 2015-08-29 04:23:44

> I wrote a patch this week and got it r+’ed, so it should be ready to land.

Excellent news, thanks + congrats!

> Note that even once the patch is landed, it will probably be a while before it can be used in Tails. The next Firefox ESR, which is what Tor Browser is based on, will be Firefox 45 and won’t be released until March 2016.

> On the other hand, the patch I wrote is pretty small and affects code that doesn’t get changed much, so if Tails wanted to maintain a temporary fork of Tor Browser with this patch available (until Firefox 45 comes out and Tor Browser upgrades to be based off of it) that should be fairly easy to do, at least in terms of keeping the patch from bit-rotting.

I’d rather not block this on building Tor Browser ourselves (that is Feature #7965 + do it in several places so we can check reproducibility since once we modify it we can’t compare with the official one). But I’m confident that once the patch has been merged upstream, the Tor Browser team will be happy to take it in their tree until ESR45 is out => wanna ask them?

(In passing, I believe the TBB team has deliverables with deadlines approaching fast about providing sandboxing/confinement profiles, so they might need this patch anyway if they don’t want to live with that UX regression.)

#29 Updated by intrigeri 2015-09-17 01:45:09

Setting the print.print_to_filename preference /home/amnesia/Tor Browser/mozilla.pdf seems to be enough to fix the problem for the “Print to file” functionality. We should probably split this ticket into two, one about “print to file”, the other about “upload”, since they’ll likely have vastly different solutions (and possibly different resolution timelines).

#30 Updated by bertagaz 2015-09-23 01:32:05

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

#31 Updated by intrigeri 2015-12-14 09:55:40

  • Target version changed from Tails_1.7 to Tails_2.0

Garrett, it seems that your patch to Firefox hasn’t been merged yet, and the upstream ticket has no owner. What’s the status?

#32 Updated by garrettr 2015-12-14 12:12:25

intrigeri wrote:
> Garrett, it seems that your patch to Firefox hasn’t been merged yet, and the upstream ticket has no owner. What’s the status?

Thanks for the poke, I got derailed waiting for my Mozilla commit access to get reinstated (got it, eventually) and with some problems I was having with their testing/review workflow, which has been changing recently. I’m revisiting the patch now and will see if I can get a test run going today.

#33 Updated by intrigeri 2015-12-14 12:48:11

Excellent!

#34 Updated by garrettr 2015-12-14 18:17:13

intrigeri wrote:
> Excellent!

Updated status in upstream bug comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1194893#c18

#35 Updated by garrettr 2015-12-18 14:23:42

garrettr wrote:
> intrigeri wrote:
> > Excellent!
>
> Updated status in upstream bug comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1194893#c18

I got the patch landed! https://bugzilla.mozilla.org/show_bug.cgi?id=1194893#c32

The only problem is that it landed in Firefox 46, but Firefox 45 is slated to be the base for the next ESR release (in March 2016): https://www.mozilla.org/en-US/firefox/organizations/faq/. That means this patch won’t be available in ESR, and therefore won’t be available in Tor Browser because Tor Browser is based on ESR.

The solution to this is to uplift the patch into Firefox 45, which should be pretty easy because it’s a small patch (although justifying it might be difficult, since it’s only benefiting Tails and not Mozilla). I’ll tackle that next.

#36 Updated by intrigeri 2015-12-18 15:08:43

> I got the patch landed!

Woooohooo! Congrats and many thanks :)

> […] it’s only benefiting Tails and not Mozilla)

Thankfully I think you have a stronger argument than that. My understanding is that it’s potentially beneficial in all environments where one wants to confine Firefox in a way that blocks its access to the user’s Desktop. E.g. Tor Browser developers wish to do this kind of things some day. Perhaps there would be more such environments around if the code supported their use case better :)

(Off-topic, please follow up on Bug #10141 if you wish instead of here — this one may be of some interest for you too: https://bugzil.la/1205598)

#37 Updated by intrigeri 2016-02-18 20:48:53

  • Target version changed from Tails_2.0 to Tails_2.2

(Tails 2.0 was released and I’d like to close the corresponding target version in Redmine accordingly.)

Any news regarding backporting the patch to ESR45?

#38 Updated by anonym 2016-03-29 18:15:31

  • Target version changed from Tails_2.2 to Tails_2.3

Post-poning since Tails 2.2. has been out for a while now. Any news on this, garrettr?

#39 Updated by anonym 2016-05-08 05:10:26

  • Target version changed from Tails_2.3 to Tails_2.4

#40 Updated by anonym 2016-06-08 01:34:56

  • Target version changed from Tails_2.4 to Tails_2.5

#41 Updated by intrigeri 2016-07-30 08:44:34

  • Target version changed from Tails_2.5 to 284

Worst case we’ll have it in Tails 2.12 or something, that will include a Tor Browser based on Firefox ESR 52.

#42 Updated by anonym 2016-11-25 10:57:20

  • Target version changed from 284 to Tails 2.10

#43 Updated by anonym 2017-01-24 20:48:45

  • Target version changed from Tails 2.10 to Tails_2.11

#44 Updated by intrigeri 2017-03-03 08:10:45

  • Assignee changed from garrettr to anonym
  • Target version changed from Tails_2.11 to Tails_3.0
  • Parent task set to Feature #12115
  • Type of work changed from Research to Test

Giving up on the uplift => next step is to verify it’s indeed fixed in FF52ESR.

#45 Updated by intrigeri 2017-05-16 09:04:31

#46 Updated by intrigeri 2017-05-16 09:04:42

  • blocked by Feature #12115: Migrate to Tor Browser based on FF52 added

#47 Updated by intrigeri 2017-05-20 07:20:35

Feature #12115 is done so we can now proceed here.

#48 Updated by anonym 2017-06-12 16:07:23

  • Target version changed from Tails_3.0 to Tails_3.1

#49 Updated by intrigeri 2017-06-29 10:32:23

#50 Updated by anonym 2017-07-06 14:15:04

  • Target version changed from Tails_3.1 to Tails_3.2

#51 Updated by intrigeri 2017-09-07 08:58:16

  • Subject changed from Spurious "permission denied" error when trying to upload files or to print to PDF from Tor Browser to Spurious "permission denied" error when trying to upload files from Tor Browser
  • % Done changed from 10 to 20
  • Type of work changed from Test to Code

Wrt. printing, commit:42d11c160daf7a819952cc546555fc9b53cc2384 (October, 2015) removed the workaround in our test suite because “The warning is not shown any more”.

Wrt. uploading files, I still see the error about failing to read /home/amnesia/Desktop. That’s expected since we did not do anything yet to take advantage of garrettr’s patch (https://bugzilla.mozilla.org/show_bug.cgi?id=1194893) that’s included in FF52ESR. So next step is to set whatever pref this patch adds to point to our “Tor Browser” directory. I expect it’ll be very simple, so leaving this on anonym’s plate for 3.2.

#52 Updated by anonym 2017-09-15 02:21:32

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

Applied in changeset commit:cba706ba532e80a6a3b997e7499f70e2604633a3.

#53 Updated by intrigeri 2017-09-15 07:38:12

  • Assignee deleted (anonym)
  • QA Check set to Pass

Reviewed, LGTM!

#54 Updated by intrigeri 2017-09-15 07:39:03

I forgot to make it clear: manual testing passes too. Yeah, less AppArmor-related UX pain, /me happy :)

#55 Updated by anonym 2017-09-28 18:49:13

  • Status changed from Fix committed to Resolved