[pkg-apparmor] Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file

[intrigeri]

Control: reassign -1 printer-driver-cups-pdf

Hi,

Martin-Éric Racine:
> This very much seems like an issue caused by AppArmor. Reassigned.

Indeed, the denial is caused by AppArmor.
Thanks for bringing this to our attention!
Now, I doubt the apparmor package is where we can fix this.

My understanding is that Rudolf customized his cups-pdf configuration
to write PDF output to a non-standard location:

>> -- Configuration Files:
>> /etc/cups/cups-pdf.conf changed:
>> Out ${HOME}/Transport

… which makes the cups-pdf AppArmor profile (shipped by the
cups-daemon package in the /etc/apparmor.d/usr.sbin.cupsd file)
unhappy:

>> -- audit error message:
>> audit[11578]: AVC apparmor="DENIED" operation="mknod" profile="/usr/lib/cups/backend/cups-pdf" name="/home/rudi/Transport/home_rudi_Transport.pdf" pid=11578 comm="gs" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

Generally, there are three strategies available to deal with this
kind of problems:

A. Generate AppArmor policy dynamically, on service startup, depending
   on the service configuration

   This is, for example, what libvirt, Samba, and others do. It's the
   nicest way to handle this as it requires no action from the user.

   Depending on the service specifics, it may be anything between
   "rather easy" and "tons of work".

   If you choose this option, then this bug should be reassigned to
   cups-daemon.

B. Document the need to adjust AppArmor policy when changing default paths

   This is less nice to affected users but it's very cheap, and
   sometimes it's good enough. For example, when there's little
   incentive to change the default paths, so in practice very few
   users are affected (which may make the cost/benefit of implementing
   option A too big to be worth it).

   Here it's already kind of the case:
   https://sources.debian.org/src/cups-pdf/3.0.1-5/debian/README.Debian/#L12

   But that file incorrectly suggests that this caveat applies only to
   Ubuntu, which is not the case anymore. So I would say first thing
   is to drop the " (UBUNTU)" annotation.

   If you choose this option, then this bug should be reassigned back
   to cups-pdf.

C. Disable AppArmor confinement by default for the program that gets blocked

   It's unfortunately the best strategy when option A requires too
   much work *and* many users would be affected by the problem so
   option B is not good enough. For example, we had to do that
   for Thunderbird.

   In the case at hand, I don't what proportion of cups-pdf users
   change the default output path. It seems that reportbug includes
   this information so one could gather some quick'n'dirty data from
   the BTS, which would help us make a reasonable assessment.

   If you choose this option, then this bug should be reassigned to
   cups-daemon.

None of these strategies can be implemented in the apparmor package.
I think the maintainers of cups-pdf are the best placed to make the
call wrt. what strategy they prefer to go with, so I'm reassigning
back to cups-pdf. I'm happy to keep providing guidance and info you
might need :)

I've just usertagged this bug so it is on the AppArmor team's radar:

  https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=help-needed&user=pkg-apparmor-team%40lists.alioth.debian.org

To learn about the preferred way to bring AppArmor-related bugs to
the attention of the AppArmor team, please read:

  https://wiki.debian.org/AppArmor/Reportbug#Usertags

Cheers,
-- 
intrigeri