Bug 1559859

A quick look around shows that a single page blank x.tmp pdf file is being created in '/tmp' and that is all.

I am with firefox-52.5.1-1.el7_4.x86_64 and I don't see the file in /tmp but this is a huge problem and a regression from previous releases.

@Martin,
can we get at least a confirmation from devel and/or some hints on how to debug?

When it's a regression can you tell me which Firefox version worked fine and which version broke that? We'd need a regression range.

Also, can you please check stock ESR firefox from mozilla:
http://archive.mozilla.org/pub/firefox/candidates/52.7.3esr-candidates/build2/linux-x86_64/en-US/firefox-52.7.3esr.tar.bz2

and also recent Firefox 59.0.3 from mozilla:
http://archive.mozilla.org/pub/firefox/candidates/59.0.2-candidates/build1/linux-x86_64/en-US/firefox-59.0.2.tar.bz2

This is working for me with firefox-52.7.2-1.el7_4.x86_64, can't reproduce.

The only difference I can see that I stored to $HOME/Desktop/. Can you try to change the destination PATH or check AVC maybe SELinux denied write to /tmp for some reason?

(In reply to Tomas Pelka from comment #7)
> This is working for me with firefox-52.7.2-1.el7_4.x86_64, can't reproduce.
> 
> The only difference I can see that I stored to $HOME/Desktop/. Can you try
> to change the destination PATH or check AVC maybe SELinux denied write to
> /tmp for some reason?

Oh and I tried /tmp too with the same result, works for me.

Had chance to look at this on RHEL 7.5 system and a vanilla CentOS VM install. Both fail to create a PDF file at any chosen location.

SELinux is blocking with:

SELinux is preventing /usr/lib64/firefox/plugin-container from create access on the file mozilla.pdf.

*****  Plugin mozplugger (99.1 confidence) suggests   ************************

If you want to use the plugin package
Then you must turn off SELinux controls on the Firefox plugins.
Do
# setsebool -P unconfined_mozilla_plugin_transition 0

*****  Plugin catchall (1.81 confidence) suggests   **************************

If you believe that plugin-container should be allowed create access on the mozilla.pdf file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c '57656220436F6E74656E74' --raw | audit2allow -M my-57656220436F6E74656E74
# semodule -i my-57656220436F6E74656E74.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c
                              0.c1023
Target Context                unconfined_u:object_r:user_home_dir_t:s0
Target Objects                mozilla.pdf [ file ]
Source                        57656220436F6E74656E74
Source Path                   /usr/lib64/firefox/plugin-container
Port                          <Unknown>
Host                          ks-fett
Source RPM Packages           firefox-52.7.2-1.el7.centos.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-166.el7_4.9.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     ks-fett
Platform                      Linux ks-fett 3.10.0-693.21.1.el7.x86_64 #1 SMP
                              Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64
Alert Count                   1
First Seen                    2018-04-12 05:41:16 BST
Last Seen                     2018-04-12 05:41:16 BST
Local ID                      911f8a9b-6bc3-4125-973d-cc1566bd83c1

Raw Audit Messages
type=AVC msg=audit(1523508076.208:160): avc:  denied  { create } for  pid=2420 comm=57656220436F6E74656E74 name="mozilla.pdf" scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=file


type=SYSCALL msg=audit(1523508076.208:160): arch=x86_64 syscall=open success=no exit=EACCES a0=7f4b074022e0 a1=c1 a2=1b6 a3=0 items=0 ppid=2339 pid=2420 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm=57656220436F6E74656E74 exe=/usr/lib64/firefox/plugin-container subj=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 key=(null)

Hash: 57656220436F6E74656E74,mozilla_plugin_t,user_home_dir_t,file,create

plugin-container needs permission to create and write to a file in this case.

Also ran into this.
Any idea when this gets fixed?

Oh and i am on selinx-policy-3.13.1-192.el7_5.4 having the problem.

The issue is resolved here on RHEL 7 with:

  selinx-policy-3.13.1-192.el7_5.4
  firefox-60.1.0-4.el7_5

Could not confirm on CentOS as it has not been updated to the package versions above as yet.

Just tested: printing to pdf is working from google-chrome-stable.x86_64                                            67.0.3396.99-1 into ~/Downloads which is not working from firefox.x86_64                                              52.8.0-1.el7_5

(In reply to Gerrit Slomma from comment #15)
> Just tested: printing to pdf is working from google-chrome-stable.x86_64    
> 67.0.3396.99-1 into ~/Downloads which is not working from firefox.x86_64    
> 52.8.0-1.el7_5

google chrome is not part of RHEL / CentOS and thus not supported. This bug is all about firefox. If you are using RHEL do an update. If using CentOS, wait for the updates and then test.

I only wanted to state that this likely is no selinx-policy issue but rather a firefox issue since it is working with google chrome.
I have not said anything about wanting support for chrome and do not need any since print-to-file is working with chrome.
If it was an issue with selinux-policy it would be all the more weird that it is working a unsupported google chrome but not with a supported firefox.
Furthermore you say it is working with a new firefox but with the same selinux-policy, another indicator it is not a problem with selinux-policy since this was not updated as per your steated package version.

(In reply to Gerrit Slomma from comment #17)
> I only wanted to state that this likely is no selinx-policy issue but rather
> a firefox issue since it is working with google chrome.
> I have not said anything about wanting support for chrome and do not need
> any since print-to-file is working with chrome.
> If it was an issue with selinux-policy it would be all the more weird that
> it is working a unsupported google chrome but not with a supported firefox.
> Furthermore you say it is working with a new firefox but with the same
> selinux-policy, another indicator it is not a problem with selinux-policy
> since this was not updated as per your steated package version.

Please stop adding comment noise to bug reports.

The issue remains here on CentOS 7 with:

  selinx-policy-3.13.1-192.el7_5.4
  firefox-52.8.0-1.el7

Waiting to test with selinux-policy-3.13.1-197.el7 if released while some systems still have firefox 52.x.x.

Created attachment 1457027 [details]
Issue present still on CentOS 7 (comment 19)

When selinux-policy* packages of version 3.13.1-207.el7 are installed, the print to PDF scenario works, but the newly created mozilla.pdf file gets an incorrect context mozilla_home_t:

# sesearch -s mozilla_plugin_t -t user_home_dir_t -c file -T | grep mozilla.pdf
type_transition mozilla_plugin_t user_home_dir_t : file mozilla_home_t "mozilla.pdf"; 
#

It should be labeled user_home_t:

# matchpathcon /home/unconfined-user/mozilla.pdf 
/home/unconfined-user/mozilla.pdf	unconfined_u:object_r:user_home_t:s0
#

Switching the bug to ASSIGNED.

Milos,

I would say mozilla_home_t is right for "mozilla.pdf" file.

If the transition rule says mozilla_home_t:

# ls -Z /home/unconfined-user/mozilla.pdf 
-rw-rw-r--. unconfined-user unconfined-user unconfined_u:object_r:mozilla_home_t:s0 /home/unconfined-user/mozilla.pdf
#

then restorecon should have the same opinion:

# restorecon -v /home/unconfined-user/mozilla.pdf
restorecon reset /home/unconfined-user/mozilla.pdf context unconfined_u:object_r:mozilla_home_t:s0->unconfined_u:object_r:user_home_t:s0
#

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3111