Bug 1559859 - Print to file (PDF) does not work
Summary: Print to file (PDF) does not work
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.4
Hardware: All
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-23 12:33 UTC by Phil Wyett
Modified: 2018-10-30 10:03 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-3.13.1-197.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 10:03:08 UTC
Target Upstream Version:


Attachments (Terms of Use)
Issue present still on CentOS 7 (comment 19) (205.68 KB, image/png)
2018-07-06 14:23 UTC, Phil Wyett
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3111 None None None 2018-10-30 10:03:47 UTC

Description Phil Wyett 2018-03-23 12:33:21 UTC
Description of problem:

Print to file (PDF) does not work.

Version-Release number of selected component (if applicable):

52.7.2

How reproducible:

Always

Steps to Reproduce:
- Run firefox.
- Open webpage.
- Open menu and select print.
- Select 'Print' then 'Print to file' from dialog that appears.
- Select PDF and a location you wish to save to on disk.
- Lastly click 'Print' button to perform action.

Actual results:

PDF not created and saved to disk to disk location specified.


Expected results:

PDF created and saved to disk location specified.


Additional info:

Comment 2 Phil Wyett 2018-03-23 12:40:00 UTC
A quick look around shows that a single page blank x.tmp pdf file is being created in '/tmp' and that is all.

Comment 3 Alexander Todorov 2018-04-02 07:19:21 UTC
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?

Comment 6 Martin Stransky 2018-04-03 09:22:11 UTC
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

Comment 7 Tomas Pelka 2018-04-04 06:33:38 UTC
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?

Comment 8 Tomas Pelka 2018-04-04 06:36:07 UTC
(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.

Comment 9 Phil Wyett 2018-04-12 04:47:30 UTC
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

Comment 10 Martin Stransky 2018-04-12 10:06:55 UTC
plugin-container needs permission to create and write to a file in this case.

Comment 12 Gerrit Slomma 2018-07-01 08:43:54 UTC
Also ran into this.
Any idea when this gets fixed?

Comment 13 Gerrit Slomma 2018-07-01 08:54:45 UTC
Oh and i am on selinx-policy-3.13.1-192.el7_5.4 having the problem.

Comment 14 Phil Wyett 2018-07-01 09:25:55 UTC
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.

Comment 15 Gerrit Slomma 2018-07-01 11:51:23 UTC
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

Comment 16 Phil Wyett 2018-07-01 18:29:16 UTC
(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.

Comment 17 Gerrit Slomma 2018-07-01 20:00:10 UTC
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.

Comment 18 Phil Wyett 2018-07-01 20:26:34 UTC
(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.

Comment 19 Phil Wyett 2018-07-06 14:22:18 UTC
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.

Comment 20 Phil Wyett 2018-07-06 14:23:58 UTC
Created attachment 1457027 [details]
Issue present still on CentOS 7 (comment 19)

Comment 21 Milos Malik 2018-07-10 07:11:16 UTC
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.

Comment 22 Lukas Vrabec 2018-07-17 15:41:35 UTC
Milos,

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

Comment 23 Milos Malik 2018-07-18 07:17:07 UTC
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
#

Comment 27 errata-xmlrpc 2018-10-30 10:03:08 UTC
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


Note You need to log in before you can comment on or make changes to this bug.