Description of problem: SELinux is preventing CUPS from saving its printer configuration file /etc/cups/printers.conf. As a result, it is impossible to create new print queues that will remain present after CUPS is restarted. Version-Release number of selected component (if applicable): selinux-policy-3.0.8-64.fc8 cups-1.3.4-4.fc8 How reproducible: Always Steps to Reproduce: 1. Set SELinux to 'enforcing' 2. # lpadmin -ptest -v lpd://192.168.16.100/lp 3. Restart cups Actual results: Queue 'test' is created but disappears after cups restarted. Expected results: Queue 'test remains after cups is restarted. Additional info: The following denial is reported by SELinux: SELinux is preventing /usr/sbin/cupsd (cupsd_t) "rename" to (cupsd_etc_t) According to the CUPS source scheduler/printers.c, the process of saving the /etc/cups/printers.conf file attempts to create a temporary backup file /etc/cups/printers.conf.0 using the rename() function. This operation is being blocked by SELinux. The file /var/cups/error_log contains the following lines which confirm this: E ... Unable to backup printers.conf - Permission denied E ... Unable to save printers.conf - Permission denied E ... Unable to restore printers.conf - Permission denied
Does # restorecon -R -v /etc/cups Fix the problem? This looks like a labeling problem. Do you have any avc messages in /var/log/audit/audit.log When I executed this command on my box, it worked fine.
Yes - that fixed the problem. There are 3 avc messages each time the problem occurred: Dec 13 17:17:16 kingsview kernel: audit(1197566236.631:25): avc: denied { rename } for pid=3585 comm="cupsd" name="printers.conf" dev=dm-0 ino=430399 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=root:object_r:cupsd_etc_t:s0 tclass=file Dec 13 17:17:16 kingsview kernel: audit(1197566236.631:26): avc: denied { write } for pid=3585 comm="cupsd" name="printers.conf" dev=dm-0 ino=430399 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=root:object_r:cupsd_etc_t:s0 tclass=file Dec 13 17:17:16 kingsview kernel: audit(1197566236.632:27): avc: denied { rename } for pid=3585 comm="cupsd" name="printers.conf.O" dev=dm-0 ino=425602 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cupsd_etc_t:s0 tclass=file
Yes all of these indicate that the printers.conf file is labeled incorrectly. I have no idea how this got labeled wrong. If you are able to figure out the way this file got mislabled, please reopen this bug.
This happened to me on two systems, both running in VMWare virtual machines. In one system, I had originally installed Fedora 6 and upgraded to 8. It's possible that something unusual may have happened there earlier, which I won't be able to remember or track down. However, the other system was practically a fresh installation of Fedora 8, with all the package updates that were current at the time the bug was reported. Additionally, it know that this had happened to another person, who, like me, had upgraded his system from Fedora 6 to 8.
Then that probably means some application outside of cups created the printers.conf or some how cups got run without a transition. Tim is there something in the updates that recreates this file?
Andrew: by what means were these queues configured? For example, did they automatically appear when the printer was plugged in, or did you need use an application to configure them? If an application, which did you use (e.g. CUPS web interface, System->Administration->Printing in GNOME [this is called system-config-printer], the KDE configuration tool, ...)? I can see that you are trying to add a queue using the lpadmin tool, but I need to know which tool was used prior to that. Also, would it be possible for you to attach the printers.conf file to this bug report? There is another bug report that has similarities to this one: bug #245672.
Dear Tim, Thanks for the questions. Actually, there is currently no printer physically attached, nor did any printers automatically appear, to my recollection. The problem occurred shortly after installing Fedora 8, so the possibility of interference by another tool is minimal. I have re-partitioned my hard disk and am currently re-installing a clean Fedora 8. All the default installation options are being used. I will try to reproduce the bug and let you know how I go. I will try to attach a relevant printers.conf file as soon as I can.