When printing to PDF, if the name of the page you're printing already exists, it will silently discard the print job

[Tom Haddon]

This is on Gusty i386.

If you print a page to PDF, and then try to reprint the same page, for instance a day later, it will silently fail to print. I would expect that it would choose a unique name (perhaps by appending a number), rather than failing to print altogether.

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.
 We have instructions on debugging some types of problems. http://wiki.ubuntu.com/DebuggingProcedures
At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).
Thanks!

[Tom Haddon (mthaddon)]

Steps to reproduce:

1. Visit slashdot.org in firefox
2. Type CTRL+P and then select "PDF-Printer" as the printer
3. Note that the document has been created in ~/PDF/ as Slashdot__News_for_nerds__stuff_that_matters.pdf
4. ls -lh on that document so that you see the date of the document
5. Wait for more than 1 minute
6. Refresh the page and print it again using the same procedures
7. ls -lh on the same document and note that the timestamp has not changed and there is not other document in the PDF directory with a similar name

Expected behaviour:

The document is printed and given a name that allows it to be recognized but still unique.

[SK (stephantom)]

Confirmed with Gutsy final and Hardy.

[Till Kamppeter (till-kamppeter)]

This looks like a problem of the upstream architecture of cups-pdf. It should overwrite the old file with a new file if the names are not changed from job to job.

[Tom Haddon (mthaddon)]

Actually, it shouldn't overwrite either. It should either pop up a choose filename dialog, or choose a unique name (perhaps by appending a sequenced number to the filename). Should this bug be forwarded upstream?

[Martin-Éric Racine (q-funk)]

This is not a bug, this is a feature. The file can either be
overwritten or get a job number appended. This is all configurable and
there is no ideal default. However, because Ubuntu chose to use
AppArmor, I wouldn't be surprised if this is being prevented from
working by AppArmor.

On 12/6/07, Tom Haddon <email address hidden> wrote:
> Actually, it shouldn't overwrite either. It should either pop up a
> choose filename dialog, or choose a unique name (perhaps by appending a
> sequenced number to the filename). Should this bug be forwarded
> upstream?
>
> --
> When printing to PDF, if the name of the page you're printing already exists, it will silently discard the print job
> https://bugs.launchpad.net/bugs/161222
> You received this bug notification because you are a bug contact for
> cups-pdf in ubuntu.
>

--
Martin-Éric Racine
http://q-funk.iki.fi

[Tom Haddon (mthaddon)]

The file is not being overwritten or getting a job number appended - it is being silently dropped...

[Martin-Éric Racine (q-funk)]

Yes and I suspect that AppArmor is the cause, since this works fine on Debian.

On 12/6/07, Tom Haddon <email address hidden> wrote:
> The file is not being overwritten or getting a job number appended - it
> is being silently dropped...

--
Martin-Éric Racine
http://q-funk.iki.fi

[Till Kamppeter (till-kamppeter)]

Can you do

sudo aa-complain cupsd

and see whether the file now gets overwritten? Can you also look for messages containing "audit" in the output of "dmesg" and in the file /var/log/messages?

[Tom Haddon (mthaddon)]

After typing

sudo aa-complain cupsd

the file is now being silently overwritten rather than silently dropped. Here's the output of "dmseg | grep audit":

dmesg | grep audit
[ 10.189164] audit: initializing netlink socket (disabled)
[ 10.189182] audit(1196931018.944:1): initialized
[ 11.846885] AppArmor: AppArmor initialized<5>audit(1196931020.944:2): type=1505 info="AppArmor initialized" pid=1273
[ 19.976000] audit(1196931037.270:3): type=1503 operation="inode_permission" requested_mask="a" denied_mask="a" name="/dev/tty" pid=5125 profile="/usr/sbin/cupsd"
[25950.892000] audit(1196956968.247:4): type=1503 operation="capable" name="dac_override" pid=11714 profile="/usr/lib/cups/backend/cups-pdf"
[25950.892000] audit(1196956968.247:5): type=1503 operation="capable" name="dac_read_search" pid=11714 profile="/usr/lib/cups/backend/cups-pdf"
[26008.200000] audit(1196957025.751:6): type=1503 operation="capable" name="dac_override" pid=11743 profile="/usr/lib/cups/backend/cups-pdf"
[26008.200000] audit(1196957025.751:7): type=1503 operation="capable" name="dac_read_search" pid=11743 profile="/usr/lib/cups/backend/cups-pdf"
[26008.264000] audit(1196957025.751:8): type=1503 operation="inode_permission" requested_mask="rw" denied_mask="r" name="/home/mthaddon/PDF/Slashdot__News_for_nerds__stuff_that_matters.pdf" pid=11746 profile="/usr/lib/cups/backend/cups-pdf"
[26043.228000] audit(1196957060.753:9): type=1502 operation="capable" name="dac_override" pid=11757 profile="/usr/lib/cups/backend/cups-pdf"

[Till Kamppeter (till-kamppeter)]

Thank you, so it is an AppArmor config issue, moving to CUPS ...

[Martin Pitt (pitti)]

Fixed in svn head.

[Tom Haddon (mthaddon)]

Could you explain how this is fixed? Does it now overwrite the existing file, or create a new file with a unique name?

[Martin Pitt (pitti)]

Tom Haddon [2008-03-19 16:35 -0000]:
> Could you explain how this is fixed? Does it now overwrite the existing
> file, or create a new file with a unique name?

I merely fixed the cupsys AppArmor profile to allow read-write access
to ~/PDF to cups-pdf (the AppArmor violation reported above).
Everything else must be done by cups-pdf itself (such as deciding
whether to add a suffix or overwrite). As Martin-Eric explained above,
the current implementation overwrites.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cupsys - 1.3.6-3ubuntu1

---------------
cupsys (1.3.6-3ubuntu1) hardy; urgency=low

  * Merge recent bug fixes and security fix from Debian unstable.

cupsys (1.3.6-3) unstable; urgency=high

  [ Till Kamppeter ]
  * pdftops-cups-1.4.dpatch: Updated to Mike Sweet's patch version from CUPS
    STR #2716.
  * debian/patches/ppd-poll-with-client-conf.dpatch: If there is a client.conf
    pointing to a remote server, clients were not able to poll the PPD options
    from printers on that server (CUPS STRs #2731, #2763)

  [ Martin Pitt ]
  * Urgency high due to security fix.
  * debian/local/apparmor-profile: Allow cups-pdf to read files in ~/PDF/, so
    that it can overwrite files. (LP: #161222)
  * Add cgiCompileSearch_buffer_overflow.dpatch: Fix buffer overflow in
    cgiCompileSearch() using crafted search expressions. Exploitable if
    printer sharing is enabled. (CVE-2008-0047, STR #2729, Closes: #472105)

 -- Martin Pitt <email address hidden> Sat, 22 Mar 2008 12:48:56 +0100