cups-pdf fails bad status reported and no pdf created

I think is NOT a duplicate of https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/295318
because it doesn't work even if i create a PDF dir under my home directory...

Thank you

I confirm this bug as i got the same problem.
Ubuntu : 8.10 x86
cups-pdf : 2.4.8-1ubuntu1

see https://answers.launchpad.net/ubuntu/+source/cups-pdf/+question/50656

I confirm this in my Intrepid Ibex.

For me cups-pdf worked with Ubuntu 8.04 (Hardy), but after the upgrade to Intrepid, the cups-pdf hasn't worked.

I can confirm this bug with same problems: it show a "/usr/lib/cups/backend/cups-pdf failed" status into printing window (or from localhost:631)

/var/log/cups/error_log :
(/usr/lib/cups/backend/cups-pdf) stopped with status 5!

I can confirm the above mentioned bug on my Ubuntu 8.10 (Intrepid).

I also changed permissions on /usr/lib/cups/backend/cups-pdf with:

sudo chmod 755 /usr/lib/cups/backend/cups-pdf

and made the failed status on the printing window go away as marcobra did.

I created the PDF folder in my home folder, but still no pdf files can be printed.

No error in the /var/log/cups/error_log appears with the 755 permissions.
With 700 permissions i get a "stopped with status 5!" error.

I can also confirm this, with the same results as papukaija.

I think I have the same issue. I cannot add a PDF printer in the printer configuration tool.
But the 'print to file' option works with pdf and ps formats.

Starting cups thru terminal results in error message:

username@Pascal:~$ sudo /etc/init.d/cups start
* Starting Common Unix Printing System: cupsd cupsd: Child exited on signal 15!
                                                                                                                                                                       [fail]
username@Pascal:~$

Confirming here also (Intrepid) . Using Intrepid, attempting to print to PDF logged as a normal user in KDE causes « (/usr/lib/cups/backend/cups-pdf) stopped with status 5! » and no PDF is generated.

However, using the CUPS web interface (http://localhost:631), logged there as "root", trying to print the PDF printer test page works and produces a printer test page PDF in /root/PDF.

what does your /var/log/cups/cups-pdf_log say?

if it says "[ERROR] failed to create directory (/home/username/PDF)" then your home directory possibly lacks the permissions required by cups-pdf

try:

ls -l /home

to check the permissions on your users' directories

rossg@rossg-workstation:~$ ls -ld /home/rossg
drwxr-xr-x 85 rossg rossg 4096 2008-11-29 23:28 /home/rossg
root@rossg-workstation:~# ls -l /home/rossg/PDF
lrwxrwxrwx 1 rossg rossg 11 2008-11-10 11:35 /home/rossg/PDF -> Private/PDF
root@rossg-workstation:~# tail /var/log/cups/cups-pdf_log
Sun Nov 30 08:21:25 2008 [ERROR] failed to create directory (/home/rossg/PDF)
Sun Nov 30 08:21:25 2008 [ERROR] failed to create user output directory (/home/rossg/PDF)

Paul Sinnett:
/var/log/cups/cups-pdf_log is empty

ls -ld /home/user/
drwxrwx--- 71 user user 4096 2008-12-03 20:21 /home/user/

ls -l /home/user/PDF/
yhteensä 0 (yhteensä=total)

ls -ld /home/user/PDF/
drwxr-xr-x 2 user user 4096 2008-11-14 20:34 /home/user/PDF/

confirm same problem here, intrepid.

My ~/PDF/ is empty.

Printing a test page to the PDF printer via localhost:631, gives me this new file:

$ find /var/spool/cups-pdf/
/var/spool/cups-pdf/
/var/spool/cups-pdf/SPOOL
/var/spool/cups-pdf/ANONYMOUS
/var/spool/cups-pdf/ANONYMOUS/Test_Page.pdf

$ lpr -P PDF /etc/passwd

.. gives no error message, but the logs show the following:

Dec 10 04:25:45 citrus kernel: [1080014.940324] type=1503 audit(1228879545.448:28): operation="inode_permission" requested_mask="::rw" denied_mask="::rw" fsuid=1000 name="/dev/tty" pid=1423 profile="/usr/lib/cups/backend/cups-pdf"
Dec 10 04:25:45 citrus kernel: [1080014.971054] type=1503 audit(1228879545.476:29): operation="inode_create" requested_mask="a::" denied_mask="a::" fsuid=1000 name="/export/1/home/oystein/PDF/passwd.pdf" pid=1423 profile="/usr/lib/cups/backend/cups-pdf"

$ sudo less cups-pdf_log
Wed Dec 10 04:25:45 2008 [ERROR] failed to set file mode for PDF file (non fatal) (/home/oystein/PDF/passwd.pdf)

access_log:
localhost - - [10/Dec/2008:04:25:45 +0100] "POST / HTTP/1.1" 200 419 CUPS-Get-Printers successful-ok
localhost - - [10/Dec/2008:04:25:45 +0100] "POST / HTTP/1.1" 200 419 CUPS-Get-Classes successful-ok
localhost - - [10/Dec/2008:04:25:45 +0100] "POST / HTTP/1.1" 200 75 CUPS-Get-Default successful-ok
localhost - - [10/Dec/2008:04:25:45 +0100] "POST /printers/PDF HTTP/1.1" 200 2649 Print-Job successful-ok
localhost - - [10/Dec/2008:04:25:45 +0100] "POST / HTTP/1.1" 200 188 Get-Notifications successful-ok
localhost - - [10/Dec/2008:04:25:45 +0100] "POST / HTTP/1.1" 200 112 Get-Job-Attributes successful-ok

Nothing relevant in page_log or error_log.

I need to print-to-pdf, help!! :)

I got it to work. I changed the permissions on $HOME. Permissions on $HOME were 750. 755 works, 751 and 754 do not work. Permissions on ~/PDF are 700.

jpkotta (and developers): But a permission of 755 on $home ( I suppose you mean /home/username/ folder) would give other people the right to access my home folder and its content.

711 should be enough for /home/jpkotta to get files.

I confirm bug with "/usr/lib/cups/backend/cups-pdf failed" status.
I have 755 on /home/username.
I have no PDF folder, or manually created PDF with permissions 700, in both cases I got same error.
In Ubuntu 8.04 its work without any manual tricks.

chmod 777 on (manually created) PDF fixes it, i now able to get nice PDFs.

for me only this command solved the problem:
sudo aa-complain cupsd

after that command, I printed a pdf, the PDF folder appear in my HOME folder with the pdf inside.

LGDN

I had the same problem.
Following works for me:
mkdir ~/PDF
chmod 777 ~/PDF

I've had the same problem (Intrepid). I already had the PDF directory (755) from Hardy. My workaround: chmod 711 ~, do print to PDF, then chmod 700 ~ again.

I think that there are two connected problems.

1) cups-pdf fails to create PDF directory (bug #295318)
2) cups-pdf cannot navigate to PDF directory, because $HOME needs at least 001 (o=x) permissions

Oddly, even though cups-pdf needs execute permission to $HOME given to other (001), it doesn't need write permission to ~/PDF.

To clarify, I think that this bug affects those who have home directory permissions of 700 or similar. Those who fixed the problem by just creating ~/PDF really want bug #295318.

Thank you, Le Gluon Du Net. That workaround worked for me, and I have my PDF folder as a systemlink to a folder on another partition.

Confirmed. The following workaround even with PDF as a symlink to an encrpyted Private/PDF :)

$ sudo aa-complain cupsd
Setting /etc/apparmor.d/usr.sbin.cupsd to complain mode.

Thanks, Le Gluon Du Net.

I have the same problem, can't print with cups-pdf printer in ubuntu 8.10
It returns failed when i try to run a test page, even with 777 rights on /home/user/PDF
Thanks for a solution

Chmoding ~ to 711 worked for me too. I wonder why cups need to enter ~ but not to write in ~/PDF...

Actually, printing into pdf only works for me if my ~ is 711 *and* /usr/lib/cups/backend/cups-pdf is suid (4755). The permissions for my home dir don't solve the problem by themselves, and neither does chgrp-ing ~/PDF to lp and adding myself to the lp group.

I have spent some time with this bug my solution was to remove cups-pdf, then create a directory ~/PDF.
I then reinstalled cups-pdf and was able to print to pdf first time.
I didn't have to change permissions on /usr/lib/cups/backend/cups-pdf or ~/PDF this time. it just worked. Hope this helps.

I have the same problem: trying to print a pdf in Ubuntu 8.10 gives the error message "usr/lib/cups/backend/cups-pdf failed".

Changing the permission to o+x of my home directory solves this problem. But after changing it back to o-x the problem comes back.

Under Ubuntu 8.04 everything worked well.

I don't want to permanently give execute access to my home directory... Isn't there any solution in the meantime?

Thanks a lot for all!

I'm pretty sure that it's not a bug in cups-pdf but a bug in the AppArmor configuration for cups-pdf.

Workaround (and proof that it's an AppArmor configuration issue):

open the file /etc/apparmor.d/usr.sbin.cupsd

and edit the line:
    /usr/lib/cups/backend/cups-pdf {
in order to get:
    /usr/lib/cups/backend/cups-pdf flags=(complain) {

restart AppArmor with 'sudo /etc/init.d/apparmor restart'

CUPS-PDF works again, QED!

As far as I understand it, the workaround removes the protection around cups-pdf, someone with more knowledge can probably fix the config file in a more sensitive manner.

As the file /etc/apparmor.d/usr.sbin.cupsd comes with the 'cups' package, this bug should be reassigned.

Hope this helps, Eric

Eric: This should be the same as running sudo aa-complain cups or sudo aa-complain cups-pdf.

confirming jellis47 solution
1. remove PDF printer from administration->printing
2. remove cups-pdf via administration->synaptic package manager
3. remove PDF folder in your home folder
4. create PDF folder in your home folder
5. install cups-pdf via administration->synaptic package manager

Thank you jellis47 and MaxFox, your solution worked for me.

I'd just reinstalled my Ubunto and now I have a 8.10 version on an amd64 machine.

The solution from Le Gluon Du Net, as confirmed by others here, worked very well to me.

Thank you all.

running: sudo aa-complain cupsd fixed it for me. so it doesnt seem to be an issue of cups-pdf actually

aptitude reinstall cups-pdf worked for me

 Eric L.'s fix to /etc/apparmor.d/usr.sbin.cupsd
and a restart of AppArmor fixed it on my system

Neither reinstalling cups-pdf nor messing with $HOME/PDF did any good.

Hi !

Like Eric says, it's a problem in the AppArmor configuration. His workaround works well but it remove the protection over cups-pdf. Like we see in the dmesg posted by marcobra it looks like a capabilities problem for /usr/lib/cups/backend/cups-pdf :

---
[89144.961555] type=1503 audit(1226146931.033:19): operation="capable" name="dac_read_search" pid=13513 profile="/usr/lib/cups/backend/cups-pdf"
[89168.118889] type=1503 audit(1226146954.189:20): operation="capable" name="dac_override" pid=13725 profile="/usr/lib/cups/backend/cups-pdf"
---

If you don't want disable protection of cups-pdf in AppArmor, don't use the flags=(complain).

Go to the /etc/apparmor.d/usr.sbin.cupsd and in the /usr/lib/cups/backend/cups-pdf section search for this lines :

  capability chown,
  capability fowner,
  capability fsetid,
  capability setgid,
  capability setuid,

after this lines you just need to add this two new lines :

  capability dac_override,
  capability dac_read_search,

It would be suficient. You juste need a /etc/init.d/apparmor reload and cups-pdf would works well !!

Hope this helps, Bruno

PS : Sorry for my english ;-)

Bruno M's explanation works for me as well, and is surely much more secure than my first solution.

Could someone integrate it in the next version of cups?

Thanks, Eric

Bruno M's solution worked well for me.

As a word of warning, if you've changed the output path in cups-pdf.conf, you need to make sure that the path in the /usr/lib/cups/backend/cups-pdf section of /etc/apparmor.d/usr.sbin.cupsd is updated too

e.g. change @{HOME}/PDF and @{HOME}/PDF/* to the right place.

Thanks,

Phil

The Jaunty RC still has this problem, as far as I can see.

I still have this problem on 9.04. It is a very short time to final release of Jaunty.

Mariusz: Jaunty repositories are frozen at the moment.

Problem in 9.04 resolved by creating ~/user/PDF and running "$ sudo aa-complain cupsd"
This trips up nearly every newbie, and whilst it may be an early right of passage, it would be nice if this were finally updated as default. It turns new people off of Ubuntu and the energy used in this and similar supports would probably meet the energy needs of a small country.

Actually, as long as Execute permissions exist on ${HOME}, the CUPS-PDF backend should be able to create ${HOME}/PDF itself if it's not there. This means that having either 711 or 751 permissions on ${HOME} should be enough.

After checking with Ubuntu developers and CUPS maintainers, it appears that default home directory permissions when adding new users is 755, so this should work for default installations. If it doesn't, we'd like to hear more details.

In other cases, as long as group Others has Execute permissions over ${HOME}, it should be enough. Thus, 711 or 751 should work. However, since permissions other than 755 on ${HOME} are non-default, we cannot guarantee that we'll support that particular case.

Just upgraded to 9.04 from 8.10.

/usr/lib/cups/backend/cups-pdf permissions:
-rwx------ 1 root root 21976 2009-02-14 23:47 cups-pdf

home folder permissions:
drwxr-x--x 115 george george 4096 2009-04-26 12:54 george

PDF folder inside home folder permissions:
drwxr-x--- 2 george george 4096 2009-04-26 12:34 PDF

also i attach my /etc/apparmor.d/usr.sbin.cupsd

everything works ok with 751 home folder permissions, but not with 750.

I consider this fixed for me.

Thank you all!

In my Ubuntu 9.04, I had to do "sudo aa-complain cupsd". Now it works ok.

/usr/lib/cups/backend/cups-pdf:
-rwx------ 1 root root 21976 2009-02-14 22:47 cups-pdf

/home/krzysiek:
drwx------ 86 krzysiek krzysiek 12288 2009-05-04 16:24

~/PDF folder was created automatically with the following permissions:
drwx------ 2 krzysiek krzysiek 4096 2009-05-04 16:24

Thanks.

Simply running this solved the problem.
$ sudo aa-complain cupsd

The ~/PDF folder was then automatically created when I printed to pdf.

Defect exists in Ubuntu 9.04.

I am NOT able to work-around this using the uninstall/reinstall procedure mentioned in above thread.

I AM able to work around this using François Letendre solution of:

$ sudo aa-complain cupsd

The workaround definitely works and AppArmor should print out logs of the offending operation... but where are the logs?

right, still existing in Jaunty and the setting it to complain mode fixed it.

There should be a fix for this since users don't always google for bugs and I'm sure it'll turn them off.

MaxFox's suggestion worked. I could not add New cups PDF printer to new Jaunty install until following his steps.

1. remove PDF printer from administration->printing
2. remove cups-pdf via administration->synaptic package manager
3. remove PDF folder in your home folder
4. create PDF folder in your home folder
5. install cups-pdf via administration->synaptic package manager

Ubuntu rocks!

MaxFox's suggestion (comment #32) did not work for me. In addition, no amount of file permission changes worked for me. I am using Ubuntu 9.04 x86_64 (2.6.28-11-generic #42-Ubuntu SMP).

However, the following did work. I changed the line #85 in /etc/apparmor.d/usr.sbin.cupsd

- /usr/lib/cups/backend/cups-pdf Px,
+ /usr/lib/cups/backend/cups-pdf Ux,

Then 'sudo /etc/init.d/apparmor reload'

I do not know whether this solution is more or less secure than previously mentioned AppArmor changes nor did I try them. I did not find much documentation on the AppArmor website that explained the difference between U and P. That being said, I am able to keep $HOME set to 0700 and $HOME/PDF set to 0700.

I'd really like to hear more about what this change from P to U implies, from a security perspective, especially given how these very same settings were working fine until Intrepid. For all we know, something changed in the kernel's security model that might have introduced regressions, while our settings would normally work. Can someone more familiar with AppArmor and the kernel features it uses confirm or infirm this guess?

"Px" means "protected by a profile", we ship one for cups-pdf. "Ux" means "unlimited", i. e. there is no AppArmor confinement whatsoever for cups-pdf. See "man apparmor.d".

Indeed you need world-executable permissions on your home directory nowadays (just like with apache, etc.). We install home directories as 755 by default, so this is not a problem in a default installation.

BTW, "sudo chmod 777 /usr/lib/cups/backend/cups-pdf" is VERY VERY VERY VERY wrong! Please don't change permissions on those backends if you don't know for sure what that does. First you have a world-writable file in your system now which anyone can tamper with to create a local root exploit, and second this causes cups-pdf to not run as root any more. It needs to be root in order to function at all. Please change it back to 700.

Indeed, so changing the cups-pdf section in the cupsd AppArmor profile is the wrong answer. This then points to possible regressions in AppArmor, on an existing configuration that, until Intrepid, worked out of the box.

I'm thus reassigning this to apparmor.

As we noticed, this is an AppArmor issue and the AppArmor profile for cups-pdf ships with CUPS, so we're invalidating the CUPS-PDF part of this bug.

Is this bug fixed in Karmic?

https://wiki.ubuntu.com/DebuggingApparmor

This is a duplicate of bug 224365. Unfortunately I cannot mark it as such, since bug 294929 is already a duplicate of this one, but I can't seem to see bug 294929.

It was fixed in Karmic in

cups (1.3.10-4) unstable; urgency=low

  * Add ghostscript-cups dependency. (LP: #385606)
  * debian/control: Add back dropped comma, which led to the ssl-cert
    dependency being dropped. (Closes: #532845)
  * debian/local/apparmor-profile: Allow reading /proc/sys/crypto/**.
    (LP: #335898)
  * debian/local/apparmor-profile: Allow dac_override to cups-pdf. This is
    unfortunate, but required with some $HOME permissions; the profile is very
    tight, so this shouldn't actually considerably increase privileges.
    (LP: #224365)

 -- Martin Pitt <email address hidden> Fri, 12 Jun 2009 11:32:28 +0200

Well, I've tried all the fixes in this thread (Jaunty/9.04), and STILL no working cups-PDF. Forced uninstall/reinstall (purging out all settings), setting permissions, setting AppArmor, etc. Nada, squat, nothing.

Have even checked that I had Ghostscript installed (suggested elsewhere). Still nothing.

What else should I try? As an alternative, someone who understands what is *supposed* to be the setup should define a single listing of precisely what settings should be where.

I think I found a solution (or at least one other thing to fix). I ran the command:

sudo chmod +s /usr/lib/cups/backend/cups-pdf

and it started working for me. There's been plenty of other "chmod" commands listed above for this file, but none that did a "set user ID". So just add it to the list of things that may or may not work for you.

Making the backend suid is actually a security risk. We cannot recommend this as a solution.

Well, it's either set suid and make it *WORK*, or don't set it and it's broken. Until someone can make it work *without* having to hack it, that's the solution.

This worked for me:
Say you want the PDF output in: ~/pdfout123

1. mkdir ~/pdfout123
2. go root with sudo su
3. change the out-line in /etc/cups/cups-pdf.conf to: Out ${HOME}/pdfout123
4. change the two lines in /etc/apparmor.d/usr.sbin.cupsd to: @{HOME}/pdfout123/ rw, and @{HOME}/pdfout123/* rw, respectively. (mind the space before rw and the comma after it)
4a. do *not* backup usr.sbin.cupsd to a file in the same dir because apparmor iterates over the files and will try
to load them all, including any .bliep.blap.blop.backup files !
5. /etc/init.d/apparmor stop
6. /etc/init.d/apparmor start
6a. ** restart won't work and restart will also not complain about duplicate files loaded, so stop and then start apparmor.
7. /etc/init.d/cups restart

Now try to print someting to the PDF-printer and it should appear in ~/pdfout123
If it does not, try a reboot. (My deepest aplogies to any Debian readers...)
If it then still does not work for you I guess I was just lucky.

FWIW:
I changed *no settings* on the /usr/lib/cups/... dirs as those are correct by default.
The first culprit is that ~/PDF is often not present.
The the second culprit is that the output-dir has to be specified in *two* /etc/config-files.
The third culprit is that apparmor does not correctly reloads changes by a simple restart.

Access on my ~/pdfout123 is: 755 (did not try other settings but logic suggests 700 should work too.

I hope this works as good for you as it did for me,
Cheers,
  Interbird.

Had same problem (9.04). did the following (don't know which one helped):
1. Added a folder named "${HOME}/PDF".
2. chmod 755 ${home}/PDF
3. sudo apt-get remove cups-pdf
4. sudo apt-get install cups-pdf
5. sudo aa-complain cupsd

after step 5 it worked, don't know if the earlier steps were necessary.

Regards,
- Aviv

Ok, I believe I have solved this problem (at least in Jaunty as I haven't tried in other versions).

1. run "sudo nano /etc/apparmor.d/usr.sbin.cupsd"
2. Add "capability dac_read_search," (no quotes and don't forget the comma at the end)
NOTE: It MUST be in the /usr/lib/cups/backend/cups-pdf section at the end. (I added it below "capability setuid,")
3. Save file and delete any backup files created if you used a different editor (or move to some other directory).
4. run "sudo /etc/init.d/apparmor stop" (no quotes)
5. run "/etc/init.d/apparmor start" (no quotes)

This worked for me.
After I found that aa-complain worked I looked at dmesg and found that apparmor was complaining about dac_read_search. I tried adding that capability in other places but it only worked as decribed above. I was sure to reset using aa-enforce to verify. I'm pretty sure this is the problem. Of course you will still have to create ~/PDF.

Hopefully this will resove your problem!

Just upgraded from Jaungty to Karmic Alpha-5 by update-manager -d.

ii cups-pdf 2.5.0-4 PDF printer for CUPS
ii cups 1.4.0-3.1 Common UNIX Printing System(tm) - server

The phenomenon is what I'm tried to print with cups-pdf printer, nothing will show up in ~/PDF

After check /var/log/cups/cups-pdf_log, it was empty and the job was queue in /var/spool/cups/

It's obvious to me something goes wrong which cups does not pass the job to cups-pdf.

Expected result:
Printed PDF show up in ~/PDF

Actual result:
No printed PDF show up

Odd, I thought that we had fixed this when we updated the AppArmor profile that comes with CUPS.

A faster but transient solution to this problem is to put apparmor into "complain" mode, like this:
$ sudo aa-complain /usr/sbin/cupsd

I believe that change will last only until the next restart of apparmor and cupsd.

I made a clean install of Karmic RC and the pdf is created normally (but with 600 as file permission).

cups-pdf broke during upgrade from 8.10 to 9.04.

Bruno MACADRE fix in #38 works for me, but still can't print to file with PDF selected.

I had this problem with Karmic. Adding

  capability dac_read_search,

To the app armor profile fixed it for me. I should note that my profile already had the following in it:

  # unfortunate, but required for when $HOME is 700
  capability dac_override,

I believe (but am not certain) that addition was the fix Martin Pitt references in comment #62, and possibly by Martin-Éric Racine in comment #71. However, my installation already had dac_override and was not working. Adding dac_read_search finally let it work. I should note that I've used the PDF printing capabilities in the past just fine and don't think I've done a version upgrade in a while.

Reopening the issue for CUPS, as per #75.

pitti, can you update the AppArmor profile according to comment #75? Thanks.

*throws hands into the air* I guess we just have to give up trying to beat any sense into cups-pdf :/ Yes, I'll add it.

Fixed in bzr.

This bug was fixed in the package cups - 1.4.6-5

---------------
cups (1.4.6-5) unstable; urgency=low

  [ Till Kamppeter ]
  * debian/patches/cups-avahi.dpatch: Updated the patch to add Avahi support
    to the newest state of the art from
    http://twaugh.fedorapeople.org/cups-avahi/ (upstream of the patch),
    in the hope to fix CUPS crashers like LP #759031, #754567, #711875,
    #751770.

  [ Martin Pitt ]
  * debian/local/apparmor-profile: Add cap_dac_read_search for cups-pdf. This
    circumvents the sandboxing even more, but with cups-pdf's architecture
    there is no way around it. (LP: #295536)
 -- Martin Pitt <email address hidden> Tue, 19 Apr 2011 06:35:38 +0000