1418240 - Firefox 57 sandbox causes issues with fonts from TeXLive

Status: RESOLVED DUPLICATE of bug 1412090

(Core :: Security: Process Sandboxing, defect)

Description

[barbas06]

Attachment: Example on Github, missing text

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171115094513

Steps to reproduce:

Visit a website with custom fonts on FF57 (Twitter, Github), with the option to allow website to use their own fonts enabled.


Actual results:

The websites do not have any text, I think the sandbox is preventing the fonts from being discovered/downloaded.

This might be related to the presence of custom fonts like the TexLive fonts as well.
In the related SO discussion [1] two workarounds are to either disable TexLive fonts, or set the security.sandbox.content.level to 1.

[1] https://askubuntu.com/questions/976985/firefox-websites-with-custom-fonts-not-displaying/977199#977199

Comment 1

[C.Krueger.B]

Same problem here, this is a real false start and show stopper of 57.
A good chunk of my usual visited websites show no text or only boxes for chars.

Applying

browser.display.use_document_fonts 0

helps too.

Comment 2

[interspicere]

I can confirm this, on Ubuntu 16.04, also with the TeXLive fonts and Roboto locally installed. 

Going to about:preferences > Language & Appearance > Advanced, and unsettin "Allow pages to choose their own fonts, instead of your selections above" resolves the issue of not seeing any text, although now all fonts are defaulted.

Comment 3

[adn]

I confirm this on Ubuntu 17.10. 

Other affected sites include:
- bugzilla.mozilla.org
- gitlab.com
- fonts.google.com

Installing texgyro (as instructed by https://askubuntu.com/a/977066/44054) solved the issue for
- github.com
- twitter.com

That I'm aware of. As others mentioned, the problem seems related to the sandbox more than to missing fonts in the system. I can confirm that before FF57 these sites where working properly on the same system, thus I highly doubt about missing fonts in the system.

Comment 4

[Domenico]

I can confirm this issue for
- Debian 9 Stretch
- KDE Neon User edition
both with TeXLive installed from CTAN.

The workaround are:
1) to install all the fonts needed (and not only texgyro...);

2) to disable "Allow pages to choose their own fonts, instead of your selections above", but in this way some sites are no longer visible;

3) rm /etc/fonts/conf.d/09-texlive.conf
   fc-cache -fsv
(but in this way TeXLive fonts are no longer recognized by the O.S. and by XeTeX)

Comment 5

[kwoid]

I can confirm this for Ubuntu 17.10 with FF57. (TeXLive installed.)

Comment 6

[Gian-Carlo Pascutto [:gcp]]

Sounds like bug 1412090. TexLive likely installs some fonts in a non-standard directory that we're not picking up.

Comment 7

[Haik Aftandilian [:haik]]

Another temporary workaround to try is to open about:config and change the preference "security.sandbox.content.level" to 2 and then restart the browser. On Linux, this reduces the strength of the sandbox to the build 56 level.

Comment 8

[Gian-Carlo Pascutto [:gcp]]

If the contents of 09-texlive.conf is this:

  <dir>/usr/share/texmf-dist/fonts/opentype</dir>
  <dir>/usr/share/texmf-dist/fonts/truetype</dir>
  <dir>/usr/local/share/texmf/fonts/opentype</dir>
  <dir>/usr/local/share/texmf/fonts/truetype</dir>

Then the recommended workaround is setting 

security.sandbox.content.read_path_whitelist to "/usr/share/texmf-dist,/usr/local/share/texmf/"

Comment 9

[Gian-Carlo Pascutto [:gcp]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #8)
> Then the recommended workaround is setting 
> 
> security.sandbox.content.read_path_whitelist to
> "/usr/share/texmf-dist,/usr/local/share/texmf/"

Disregard this, we already whitelist this:

  policy->AddDir(rdonly, "/usr/share");
  policy->AddDir(rdonly, "/usr/local/share");

What's the contents of your 09-texlive.conf?

Comment 10

[Domenico]

Here is my 09-texlive.conf:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <dir>/usr/local/texlive/2017/texmf-dist/fonts/opentype</dir>
  <dir>/usr/local/texlive/2017/texmf-dist/fonts/truetype</dir>
  <dir>/usr/local/texlive/2017/texmf-dist/fonts/type1</dir>
</fontconfig>

I added to about:config

  /usr/local/texlive/2017/texmf-dist/

and all is working.

Comment 11

[livalenz]

It affects me too, with Ubuntu 16.04, and TexLive 2017. This is a massive thing. Most of the sites I use are unworkable. Switching to Chrome now. What a total waste of time.

Comment 12

[Gian-Carlo Pascutto [:gcp]]

Recommended workaround would be to go to about:config and set:
security.sandbox.content.read_path_whitelist to /usr/local/texlive

This appears to be hitting a fair amount of people, and we are considering uplifting the proper fix from bug 1412090 into Firefox 58.

Comment 13

[francis]

I am having this problem also, but I do not have TexLive installed nor do I have a 09-texlive.conf file in the mentioned location. 

I my case I believe it is related to having all my fonts stored in a non-default location on a different drive. (I have not had any issues with my font location with other applications or previous versions of Firefox.)

Setting "security.sandbox.content.level" to 2 resolved the issue for me for now but is obviously not desirable as a long term solution.

Comment 14

[Gian-Carlo Pascutto [:gcp]]

>I my case I believe it is related to having all my fonts stored in a non-default location on a different drive.

That is correct.

>Setting "security.sandbox.content.level" to 2 resolved the issue for me for now but is obviously not desirable as a long term solution.

Adding your font path to "security.sandbox.content.read_path_whitelist" would be a better solution. Firefox can't reasonably try to parse the fontconfig configuration files so this won't be fixed until font file read-in is entirely done in the parent process, which won't happen in the near term.

Bug 1412090 will fix this for most people that have a few fonts outside the default locations, but your case where all fonts are in non-default locations will just get worse unless Firefox knows where to find them.

Comment 15

[Domenico]

(In reply to francis from comment #13)
> I my case I believe it is related to having all my fonts stored in a
> non-default location on a different drive.

I too have fonts stored in a non-default location, but I symlinked their folder with ~/.fonts. This way, you will not be forced to change any Firefox option.

Comment 16

[Ado Arnolds]

Dear Developers,

we have a setup where all our fonts are sitting below /usr/common/share/fonts. The environment is shared between several hundred users by a network filesystem (AFS). So it's not possible to change the personal setup for every user. It would be really great to see /usr/common/share/fonts added to the default accepted font path in future releases.

Thanks a lot!

Comment 17

[Gian-Carlo Pascutto [:gcp]]

You're better off symlinking that directory into a standard one then, i.e.:

ln -s /usr/common/share/fonts /usr/local/share/fonts/common

should work.

Comment 18

[Ado Arnolds]

Thanks a lot for your fast reply! Yes that would be one way, but /usr/local is architecture dependent while /usr/common is not (and as far as I know fonts are architecture independent). I just did it for testing, but it doesn't work either:

ncc-18:~% ll /usr/local/share/fonts
lrwxr-xr-x 1 arnolds root 23 Nov 22 12:13 /usr/local/share/fonts -> /usr/common/share/fonts/
ncc-18:~% ll /usr/local/share/fonts/
total 46
drwxr-xr-x 2 arnolds mpa 24576 Feb 16  2012 otf/
drwxr-xr-x 4 beb     mpa  2048 Jun 28  2016 truetype/
drwxr-xr-x 2 arnolds mpa 16384 Feb 22  2012 ttf/
drwxr-xr-x 2 arnolds mpa  4096 Feb 15  2012 type1/

I get the well known most empty web pages.

The only method I found until now, without editing the personal about:config setup, is linking the real font path to ~/.fonts

ncc-18:~% ln -s /usr/common/share/fonts .fonts

That works, but on one hand some users have their personal fonts in ~/.fonts, and on the other hand I don't like to access user directories for this change.

It would be real great to have /usr/common/share/fonts in the standard white list.

Kind regards.

Comment 19

[Ado Arnolds]

FYI: /usr/local itself is a link which is dynamically expanded depending on the architecture used. Perhaps that's the problem with the link you advised:

ncc-18:~% ll /usr/local
lrwxr-xr-x 1 daemon root 13 Nov 22 12:01 /usr/local -> /afs/mpa/@sys/

Comment 20

[Gian-Carlo Pascutto [:gcp]]

(In reply to Ado Arnolds from comment #18)
> That works, but on one hand some users have their personal fonts in
> ~/.fonts, 

Symlinking into a subdir of ~/.fonts should work just as well.

> and on the other hand I don't like to access user directories for this change.

Symlinking into any of these places will work as an alternative:

https://dxr.mozilla.org/mozilla-release/rev/3702966a64c80e17d01f613b0a464f92695524fc/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp#145

In Firefox 59, any "fonts" subdir of XDG_DATA_DIRS will also work:

https://dxr.mozilla.org/mozilla-central/rev/72ee4800d4156931c89b58bd807af4a3083702bb/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp#294

So there you could do XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/common/share in whatever script modifies the fontconfig configuration to add that path.

> It would be real great to have /usr/common/share/fonts in the standard white
> list.

I haven't seen this setup in any kind of Linux distro, FHS, FreeDesktop spec, etc, nor was it requested in the 4 months that this feature was in beta. So this seems to much of a one-off to me to add.

Comment 21

[Gian-Carlo Pascutto [:gcp]]

I'm duping this to 1412090 because that one fixes the issues for a typical TexLive install. The config some of the latter comments here describe (where users don't have any local fonts) won't work with that, but it's not related to TexLive, so it seems better to deal with it in a separate bug.

Comment 22

[Ado Arnolds]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #20)
Dear Gian-Carlo,

thank you very much for your valuable hints! With this and the pointers to the sources, I found my problem: it was in my fontconfig setup. /etc/fonts/fonts.conf specified several font dirs

<dir>/usr/share/fonts</dir>
<dir>/usr/X11/share/fonts/X11</dir>
<dir>/usr/local/share/fonts</dir>
<dir>/usr/common/share/fonts</dir>
...

where /usr/share/fonts is really a link to /usr/common/share/fonts (the real font depot). This way fontconfig finds all fonts twice:

~% fc-list "Gentium Book Basic":style=Italic file
/usr/share/fonts/ttf/GenBkBasI.ttf:
/usr/common/share/fonts/ttf/GenBkBasI.ttf:

and firefox-57 seems to prefer /usr/common/share, for which reason ever. When I added the link from ~/.fonts, all fonts were found 3 times:

~% fc-list "Gentium Book Basic":style=Italic file
/usr/share/fonts/ttf/GenBkBasI.ttf:
/usr/common/share/fonts/ttf/GenBkBasI.ttf:
/afs/mpa/home/arnolds/.fonts/ttf/GenBkBasI.ttf:

and firefox was happy again. The library calls used by firefox might return another sequence like fc-list.

By removing /usr/common/share/fonts from /etc/fonts/fonts.conf (and also removing ~/.fonts) the font detection works like expected.

Thanks again and sorry for bothering you. Perhaps my experiences might help others.

Cheers,

Ado

Comment 23

[reescf]

Recommended workaround would be to go to about:config and set:
security.sandbox.content.read_path_whitelist to /usr/local/texlive

Setting this as suggested did not work for me. I set it, changed the font preferences to allow pages to set fonts and restarted Firefox. I then changed the font preferences back to prevent this in order to see this page. 

I don't have any non-standard font directories other than those under /usr/local/texlive - not even anything in ~/.fonts. Apart from those under /usr/local/texlive, everything is in /usr/share/fonts. 

Arch Linux (current stable) with TeX Live 2017 installed from upstream.

09-texlive-fonts.conf contains:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <dir>/usr/local/texlive/current/texmf-dist/fonts/opentype</dir>
  <dir>/usr/local/texlive/current/texmf-dist/fonts/truetype</dir>
  <dir>/usr/local/texlive/current/texmf-dist/fonts/type1</dir>
  <dir>/usr/local/texlive/texmf-local/fonts/opentype</dir>
  <dir>/usr/local/texlive/texmf-local/fonts/truetype</dir>
  <dir>/usr/local/texlive/texmf-local/fonts/type1</dir>
</fontconfig>

Comment 24

[Gian-Carlo Pascutto [:gcp]]

Does changing  "security.sandbox.content.level" to 2 make the fonts appear?

If so, change it back to 3, and restart Firefox with MOZ_SANDBOX_LOGGING=1 set in the environment, and try to load an affected page. You should see log messages about the files that are blocked, including the relevant font files.

Comment 25

[C.Krueger.B]

Independent from the permission problem, I have a hard time understanding why the current behaviour is chosen in FF:

If the best fit for a font isn't available or inaccessible, why the fall-back scenario is using a font which does not make any sense at all (and not e.g. the configured default font)?

Comment 26

[Gian-Carlo Pascutto [:gcp]]

(In reply to C.Krueger.B from comment #25)
> Independent from the permission problem, I have a hard time understanding
> why the current behaviour is chosen in FF:
> 
> If the best fit for a font isn't available or inaccessible, why the
> fall-back scenario is using a font which does not make any sense at all (and
> not e.g. the configured default font)?

I don't understand what you are saying. This bug is about the fonts not showing up at all.

Comment 27

[C.Krueger.B]

> I don't understand what you are saying. This bug is about the fonts not
> showing up at all.

As far as I understood the issue it is not shown because of a access violation of the sandbox?
So which font is used instead?
None? Seems to me questionable.
I do not know how to attach a file here, otherwise I could supply a screen-shot where most chars are represented by boxes, so it seems there is some kind of fall-back?

Comment 28

[Gian-Carlo Pascutto [:gcp]]

Ah, I think you're seeing what is called "tofu" or font fallback glyphs. They are substituted if the must draw a character that is not in the font. In this case, all characters look missing to the renderer, so everything becomes tofu.

Comment 29

[Gian-Carlo Pascutto [:gcp]]

(As to why tofu are used instead of a fallback font, I don't know the answer. Because this is kind of an unexpected error state it might not be intentional.)

Comment 30

[reescf]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #24)
> Does changing  "security.sandbox.content.level" to 2 make the fonts appear?

Yes. This also works. That is, setting this and allowing pages to load their preferred fonts allows text to be rendered as expected.

> If so, change it back to 3, and restart Firefox with MOZ_SANDBOX_LOGGING=1
> set in the environment, and try to load an affected page. You should see log
> messages about the files that are blocked, including the relevant font files.

It can't load the TeX Live fonts even with /usr/local/texlive added to the whitelist. I won't post everything unless asked, but here are a couple of sample errors:

Sandbox: SandboxBroker: denied op=stat rflags=0 perms=0 path=/usr/local/texlive/current/texmf-dist/fonts/opentype/public/heuristica for pid=18075
Sandbox: Failed errno -13 op 2 flags 00 path /usr/local/texlive/current/texmf-dist/fonts/opentype/public/heuristica

and

Sandbox: SandboxBroker: denied op=stat rflags=0 perms=0 path=/usr/local/texlive/current/texmf-dist/fonts/type1/public/inconsolata for pid=18075
Sandbox: Failed errno -13 op 2 flags 00 path /usr/local/texlive/current/texmf-dist/fonts/type1/public/inconsolata

Here's the line I changed in about:config:

security.sandbox.content.read_path_whitelist;/usr/local/texlive

This is copy-pasted. There's no visible semicolon in the actual display.

/usr/local/texlive has global read access and global execute access for directories and binaries, so there shouldn't be a problem with permissions from the system side. 

Is FF by any chance checking ownership? Most people install TeX Live with root privileges. However, this is not recommended by upstream for security reasons. That's the only non-standard thing about my system I can think might make a difference.

Permissions and ownership for /usr/local/texlive/current/texmf-dist/fonts/opentype/public/inconsolata/:

drwxr-xr-x  2 texlive texlive 4.0K Meh   7 01:54 ./
drwxr-xr-x 68 texlive texlive 4.0K Med  21 02:26 ../
-rw-r--r--  1 texlive texlive  28K Rha  31  2016 InconsolataN-Bold.otf
-rw-r--r--  1 texlive texlive  26K Rha  31  2016 InconsolataN-Regular.otf
-rw-r--r--  1 texlive texlive 111K Tach 25  2016 Inconsolatazi4-Bold.otf
-rw-r--r--  1 texlive texlive  37K Rha  31  2016 Inconsolatazi4-Regular.otf

Note that I also have sandbox complaints for files which appear to be part of FF itself, although there is no 'denied' and the error is certainly different:

Sandbox: Failed errno -2 op 2 flags 00 path /usr/lib/firefox/icudt59l/curr/en.res

The logging also includes

Sandbox: using seccomp tsync
Sandbox: policy for /usr/local/texlive: 1 -> 3

And then several changes to a 'new' policy which map 3 -> 3 and presumably leave things as they are, and some '1 -> 3', which seems odd as there's never a change back to 1 as far as I can see.

Comment 31

[Domenico]

(In reply to reescf from comment #30)
> It can't load the TeX Live fonts even with /usr/local/texlive added to the
> whitelist. I won't post everything unless asked, but here are a couple of
> sample errors:

I noticed same issue too, but, when I wrote /usr/local/texlive/ (instead of /usr/local/texlive), all went fine.

Comment 32

[Gian-Carlo Pascutto [:gcp]]

Checking the code, indeed it requires the trailing /.

Comment 33

[reescf]

So the new recommended workaround would be 
> security.sandbox.content.read_path_whitelist to /usr/local/texlive/
- is that correct?

Comment 34

[reescf]

(In reply to Domenico from comment #31)
> (In reply to reescf from comment #30)
> > It can't load the TeX Live fonts even with /usr/local/texlive added to the
> > whitelist. I won't post everything unless asked, but here are a couple of
> > sample errors:
> 
> I noticed same issue too, but, when I wrote /usr/local/texlive/ (instead of
> /usr/local/texlive), all went fine.

Brilliant! This finally did it: sandbox at 3 + let sites load their preferred fonts + whitelist with trailing slash = readable https://addons.mozilla.org/en-GB/firefox/.

Is there any plan to make the whitelist configuration more obvious or accessible? It is not exactly user-friendly as it is at the moment. I know you only just discovered this issue, so this isn't a complaint. But I often answer questions on TeX SE and I can imagine already the posts about 'TeX killing Firefox', so it would be nice to know if about:config is going to be the official recommendation or if this is a temporary workaround.

Comment 35

[Gian-Carlo Pascutto [:gcp]]

>- is that correct?

Yes, my mistake for forgetting the / is needed.

>Is there any plan to make the whitelist configuration more obvious or accessible?

The about:config stuff is for workarounds, i.e. exotic configurations that we can't fully support, and there are no plans to make it easier to access - it's not something that's intended to be used by most normal users at all. We added it because we understand that Linux configurations are more diverse than on Windows or macOS and people may be running setups that are very different from "out of the box" distros.

The TexLive problem is so far the biggest fallout we have seen from the sandboxing, and while it seems to be somewhat common, it was also uncommon enough that nobody noticed it during the 4 months it was in alpha/beta versions.

We fixed the TexLive problem for Firefox 58, so the workaround won't be needed any more.

Comment 36

[reescf]

Thanks. I mainly had the TL problem in mind, as that is pretty common. MacTeX also installs fonts under /usr/local/texlive, although I am not sure whether they are seen by the OS. I suspect that FontBook may duplicate the fonts if installed for the system, but I'm not sure.

Comment 37

[Domenico]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #35)
> 
> We fixed the TexLive problem for Firefox 58, so the workaround won't be
> needed any more.

Unfortunately, not! :-(
After upgrade to Firefox 58 the workaround is still needed.

Here is a couple of sites with missing fonts:
- https://www.academia.edu/
- https://inbox.google.com/

Comment 38

[Gian-Carlo Pascutto [:gcp]]

Bug 1412090 was merged for Firefox 58, so you seem to be having another problem. Can you file a new bug?

Comment 39

[Gian-Carlo Pascutto [:gcp]]

Might be worth checking with a fresh profile too, in case any of the workarounds is now being the problem. 

Given that there were no reports of this issue for 2 months and none on Nightly, Dev Edition or Beta, now seeing out of the blue a report that it doesn't work on release is pretty heart-breaking, so anything to help debug or investigate it is welcome. But it's probably better to group that in a new bug, as this is one is already duped to the original fix.

Comment 40

[Domenico]

Please, don't consider my previous post! I can't say what appened!
I checked with clean profile and all was fine; then, I checked with my main profile (resetting the config string) and... no issues!

The only thing I can report is a poor antialiasing of fonts, for example in THIS site. I'll do more tests and tomorrow I'll fill a new bug report, if I'll find some time.

Many many thanks in advance,
DC

Comment 41

[Steven V. Wilson]

I think FF version 63 has this problem. I am trying to play Elvenar but the game reports that my browser failed to load the game. Fresh install and update of Kubuntu 10.18 released October 18, 2018.

Comment 42

[Gian-Carlo Pascutto [:gcp]]

Can you file a new bug? This one was fixed in Firefox 58 and the problem you describe ("failed to load  Elvenar") doesn't sound remotely close to anything described here.