Bugzilla – Bug 474403
AppArmor makes CUPS irresponsive
Last modified: 2009-02-24 15:58:50 UTC
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) SUSE nothing comes up if I type localhost:631 into my browser multiple error messages occure in the cups error log: I [10/Feb/2009:16:58:06 +0100] Listening to 127.0.0.1:631 (IPv4) I [10/Feb/2009:16:58:06 +0100] Listening to /var/run/cups/cups.sock (Domain) I [10/Feb/2009:16:58:06 +0100] Loaded configuration file "/etc/cups/cupsd.conf" E [10/Feb/2009:16:58:06 +0100] Unable to change permissions of "/var/run/cups/certs" - Permission denied I [10/Feb/2009:16:58:06 +0100] Using default TempDir of /var/spool/cups/tmp... I [10/Feb/2009:16:58:06 +0100] Configured for up to 100 clients. I [10/Feb/2009:16:58:06 +0100] Allowing up to 100 client connections per host. I [10/Feb/2009:16:58:06 +0100] Full reload is required. I [10/Feb/2009:16:58:06 +0100] Loaded MIME database from '/etc/cups': 37 types, 40 filters... E [10/Feb/2009:16:58:06 +0100] Unable to open job cache file "/etc/cups/yes/job.cache": Permission denied E [10/Feb/2009:16:58:06 +0100] Unable to open spool directory "/var/spool/cups": Permission denied I [10/Feb/2009:16:58:06 +0100] Full reload complete. I [10/Feb/2009:16:58:06 +0100] Cleaning out old temporary files in "/var/spool/cups/tmp"... I [10/Feb/2009:16:58:06 +0100] Listening to 127.0.0.1:631 on fd 6... E [10/Feb/2009:16:58:06 +0100] Unable to bind socket for address /var/run/cups/cups.sock:0 - Permission denied. I [10/Feb/2009:16:58:06 +0100] Resuming new connection processing... E [10/Feb/2009:16:58:06 +0100] cupsdAddCert: Unable to create certificate file /var/run/cups/certs/0 - Permission denied and when I try to access localhost:631: E [10/Feb/2009:17:00:13 +0100] cupsdAddCert: Unable to create certificate file /var/run/cups/certs/0 - Permission denied E [10/Feb/2009:17:00:13 +0100] cupsdAddCert: Unable to create certificate file /var/run/cups/certs/0 - Permission denied Looks like the error described at http://www.mail-archive.com/debian-bugs-dist%40lists.debian.org/msg348177.html How can I downgrade cups? - or is there any other way to resolve that problem Reproducible: Always Steps to Reproduce: 1. 2. 3.
Everything works well for me for opemSUSE 11.1 (and worked well in the past for all openSUSE versions). I have no idea at all why the cupsd process gets "Permission denied" errors because the cupsd has unlimited permissions because it runs as root since CUPS 1.2 i.e. since openSUSE 10.2, see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell --------------------------------------------------------------- Up to SUSE LINUX 10.1 we provided CUPS 1.1 and since openSUSE 10.2 we provide CUPS 1.2 which is not fully backward compatible with CUPS 1.1. Therefore in case of an update it is recommended not to use an outdated cupsd.conf from a CUPS 1.1 installation before but to start from scratch with the original cupsd.conf from our CUPS 1.2 RPM. --------------------------------------------------------------- Therefore I can only close the report as "worksforme". Perhaps you have whatever special add-on security stuff set up and running which could even jail root-processes like AppArmor or SELinux or whatever else? But this is not how openSUSE 11.1 is running by default.
oops; thx - in deed apparmour has confined cupsd by default; perhaps we should not activate the usr.sbin.cupsd profile by default for it simply does not work. apart from that little fallacy I think of apparmour as a very useful and user friendly security solution. its just a pity that Novell has unlessly separated from it! may we keep the thread for the usr.sbin.cupsd - profile; perhaps I wanna upload an updated version of the profile in the near future.
Many thanks for your feedback! Strange: For you AppArmor made CUPS unusable by default but for me CUPS works well out-of-the-box. I did a out-of-the-box default installation of openSUSE 11.1. I am really no AppArmor expert so that I don't know how to find out what went wrong on your system. To investigate what went wrong on your system, I reopen the issue and change the component to AppArmor so that an AppArmor expert could have a look.
Wanna close this bug for the system it has been reported for had been hacked (It does not make sense to issue an error report on a hacked system.). Works well for a clean reinstallation.
Again many thanks for your candid feedback!
What about providing Apparmor profiles out-of-the-box for sbin.rpcbind(like under Mandrake) or for Kopete, Epiphany and Thunderbird? It should be worth a recommendation to activate this right after the primary installation. Besides this something seems to be wrong with the profile for Firefox: >/etc/init.d/boot.apparmor Profile /etc/apparmor.d/usr.lib.firefox.firefox failed to load