Hide Forgot
Description of problem: Attempting to print a document using the cups-pdf facility fails. Version-Release number of selected component (if applicable): cups-pdf-2.6.1-4.fc19.x86_64 How reproducible: Always reproducible. Steps to Reproduce: 1. Open LibreOffice writer. 2. Enter text into document. 3. Order LibreOffice to print the document to "cups-pdf". Actual results: Nothing visible happens. Expected results: A PDF file should appear in ~/Desktop. Additional info: ~/.config/user-dirs.dirs is labeled "unconfined_u:object_r:default_t:s0". The cups-pdf processes (when they exist) are labeled "system_u:system_r:cups_pdf_t:s0-s0:c0.c1023". It appears that this labeling prevents the cups-pdf processes from determining where my "desktop" directory is, based on this trace output from tracing cupsd and its children: cups.29507:open("/home/worley/.config/user-dirs.dirs", O_RDONLY) = -1 EACCES (Permission denied) and on this message in /var/log/cups/cups-pdf_log: Wed Sep 18 11:58:10 2013 [ERROR] Can't read (/home/worley/.config/user-dirs.dirs) (The file permissions cannot be the problem, because the file is readable by myself, and the two cups-pdf processes have either 0 or my UID as their UID.) Problem 1: It appears that giving user-dirs.dirs the proper label would fix the access problem and allow cups-pdf to operate. What is the proper label for this file? (What is the correct command to apply this label to the file?) Problem 2: I did not manually create user-dirs.dirs, so it appears to have been created by some system process at some point in the past, possibly in an earlier version of Fedora. That suggests that the system process does not apply the correct label to the file, or that the correct label has changed over time. In either case, there should be a way for the system to recover from the mis-labeling without requiring the user to manually diagnose and correct the problem. Problem 3: When cups-pdf fails to write the PDF, it should notify the user. E.g., it could (like cron) send e-mail to the user warning them of the failure. Currently, it seems that all cups-pdf failures are silent. The system is Fedora 19. $ uname -a Linux hobgoblin.ariadne.com 3.10.11-200.fc19.x86_64 #1 SMP Mon Sep 9 13:03:01 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux with the following RPMs: cups-filters-libs-1.0.36-2.fc19.x86_64 cups-filters-1.0.36-2.fc19.x86_64 cups-filesystem-1.6.3-4.fc19.noarch cups-pdf-2.6.1-4.fc19.x86_64 cups-pk-helper-0.2.4-2.fc19.x86_64 cups-libs-1.6.3-4.fc19.i686 cups-1.6.3-4.fc19.x86_64 cups-libs-1.6.3-4.fc19.x86_64 selinux-policy-3.12.1-74.3.fc19.noarch selinux-policy-targeted-3.12.1-74.3.fc19.noarch libselinux-devel-2.1.13-15.fc19.x86_64 libselinux-python-2.1.13-15.fc19.x86_64 libselinux-utils-2.1.13-15.fc19.x86_64 libselinux-2.1.13-15.fc19.x86_64 libselinux-2.1.13-15.fc19.i686 The SELinux policy (/etc/selinux/config) is: SELINUX=enforcing SELINUXTYPE=targeted
What is the context of this file after a # restorecon /home/<username>/.config/user-dirs.dirs
(In reply to Remi Collet from comment #1) > What is the context of this file after a > # restorecon /home/<username>/.config/user-dirs.dirs Strictly speaking, that command doesn't do anything, but that is because this system's home dirs are /common/home/<username>. (/home is a symlink to /common/home.) What I did to solve this problem is: 1. Construct the proper rules in /etc/sexlinux/targetd/contexts/files/file_contexts.local to handle this system's home directory arrangement by copying all the lines that start with "/home" from /etc/sexlinux/targetd/contexts/files/file_contexts.homedirs and editing them to start with "/common/home". 2. Execute as root "/usr/sbin/semodule -B -n -s targeted" to build the file_*.bin files in that directory. 3. Execute as the user "restorecon -r /common/home/<user name>" to relabel the files in the user's home directory. This fixes this problem (as cups-pdf now generates files in ~/Desktop), although that PDF is not correct. Some other problems were revealed during this process. I will append a comment listing the related bugs, but this bug can be closed as fixed.
Related bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1005492 https://bugzilla.redhat.com/show_bug.cgi?id=1010434 https://bugzilla.redhat.com/show_bug.cgi?id=1010440 https://bugzilla.redhat.com/show_bug.cgi?id=1010444
default provided configuration and selinux policy are designed to work out the box. If the system administrator change this, he have to ensure that all works corectly. I don't see any cups-pdf bug here.