Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file
Hi,
intrigeri:
> Martin-Éric Racine:
>> At the very least, allowing anything inside /home/${USER} would
>> probably eliminate the vast majority of bug reports. Let's try it.
> Deal!
Here's a merge request implementing this proposal:
https://salsa.debian.org/printing-team/cups/merge_requests/4
Cheers,
--
intrigeri
Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file
Control: reassign -1 cups-daemon
Hi,
Martin-Éric Racine:
> ke 18. syysk. 2019 klo 12.11 intrigeri (intrig...@debian.org) kirjoitti:
>> Thinking about it a bit more, I'm wondering if a less drastic approach
>> would be acceptable:
>>
>> D. Allow cups-pdf to write anywhere under /home/*
>>
>>This still (somewhat) protects users against security issues in
>>cups-pdf. This gets rid of AppArmor denials, as long as the user
>>does not customize the "Out" setting to make it point to some place
>>that's elsewhere than under ${HOME}.
> This was considered a number of times at Ubuntu, back when it adopted
> AppArmor. While allowing anything under ${HOME} makes perfect sense
> to me (and would be a good enough compromise between security and
> configurability), there's always random people who configure an
> unusual output path e.g. /tmp/${USER} or somehow prefer upstream's
> default at /var/spool/cups-pdf/${USER}, and who immediately file a bug
> report when that doesn't work instead of checking README.Debian for
> possible instructions regarding AppArmor.
Right, I can totally see this happen. Like in many other places, here
we need to draw the line somewhere between providing better UX for
rare corner cases, and improving Debian's security for the vast
majority of our users. It's sometimes tough.
Wrt. the upstream default path: note that the AppArmor profile already
allows writing there, so this should not be a problem :)
> There's also systems where ${HOME} is, for some reason, a path other
> than /home/${USER}.
Absolutely. And then they'll have AppArmor issues for most desktop
apps that come with an AppArmor profile, until someone points them to
/etc/apparmor.d/tunables/home* (as I just did on a similar bug report
earlier today). Chances are that they notice the problem elsewhere,
and fix it somehow, before cups-pdf is involved, so at least this is
unlikely to land on *your* plate.
> At the very least, allowing anything inside /home/${USER} would
> probably eliminate the vast majority of bug reports. Let's try it.
Deal! Thanks for working constructively with me on this.
I'm thus reassigning to cups-daemon, where the file that needs
patching lives. I'll try my best to submit a patch or MR
by the end of the month. And then I'll let the printing team
decide if that's worth backporting to Buster via a stable update.
Cheers,
--
intrigeri
Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file
ke 18. syysk. 2019 klo 12.11 intrigeri (intrig...@debian.org) kirjoitti:
>
> Martin-Éric Racine:
> > ke 18. syysk. 2019 klo 10.03 intrigeri (intrig...@debian.org) kirjoitti:
> >> C. Disable AppArmor confinement by default for the program that gets
> >> blocked
> >>
> >>If you choose this option, then this bug should be reassigned to
> >>cups-daemon.
>
> > This indeed is the best option.
>
> Thinking about it a bit more, I'm wondering if a less drastic approach
> would be acceptable:
>
> D. Allow cups-pdf to write anywhere under /home/*
>
>This still (somewhat) protects users against security issues in
>cups-pdf. This gets rid of AppArmor denials, as long as the user
>does not customize the "Out" setting to make it point to some place
>that's elsewhere than under ${HOME}.
This was considered a number of times at Ubuntu, back when it adopted
AppArmor. While allowing anything under ${HOME} makes perfect sense
to me (and would be a good enough compromise between security and
configurability), there's always random people who configure an
unusual output path e.g. /tmp/${USER} or somehow prefer upstream's
default at /var/spool/cups-pdf/${USER}, and who immediately file a bug
report when that doesn't work instead of checking README.Debian for
possible instructions regarding AppArmor. There's also systems where
${HOME} is, for some reason, a path other than /home/${USER}.
At the very least, allowing anything inside /home/${USER} would
probably eliminate the vast majority of bug reports. Let's try it.
Martin-Éric
Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file
Martin-Éric Racine:
> ke 18. syysk. 2019 klo 10.03 intrigeri (intrig...@debian.org) kirjoitti:
>> C. Disable AppArmor confinement by default for the program that gets blocked
>>
>>If you choose this option, then this bug should be reassigned to
>>cups-daemon.
> This indeed is the best option.
Thanks for your feedback!
Thinking about it a bit more, I'm wondering if a less drastic approach
would be acceptable:
D. Allow cups-pdf to write anywhere under /home/*
This still (somewhat) protects users against security issues in
cups-pdf. This gets rid of AppArmor denials, as long as the user
does not customize the "Out" setting to make it point to some place
that's elsewhere than under ${HOME}.
I could try this to start with: all it takes is modifying 2 lines.
And if this still yields an unacceptable UX for users, or causes too
much BTS workload for you, then we can still do option C.
How does it sound?
Cheers,
--
intrigeri
Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file
ke 18. syysk. 2019 klo 10.03 intrigeri (intrig...@debian.org) kirjoitti: > C. Disable AppArmor confinement by default for the program that gets blocked > >If you choose this option, then this bug should be reassigned to >cups-daemon. This indeed is the best option. Bugs about issues caused by AppArmor were already common at Ubuntu when it became an early adopter of AppArmor AND when it chose DPKG build options that don't ship README. Now that Debian ships AppArmor and CUPS pulls it as a dependency, bugs about AppArmor-caused issues have started appearing here too. Martin-Éric
Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file
Hi Martin-Éric, Martin-Éric Racine: > ke 18. syysk. 2019 klo 10.03 intrigeri (intrig...@debian.org) kirjoitti: >>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. > It shouldn't. This is an AppArmor issue. AppArmor interferes with > CUPS-PDF configuration. Between the lines you wrote, what I _think_ I understand is that: - You don't particularly care how and where the problem is solved. - You'd rather not spend more time yourself on AppArmor-related issues that affect cups-pdf. - You expect AppArmor folks to solve the problem. Did I understand your position correctly? FWIW, I personally find such a position perfectly fair and reasonable. If I understood correctly that you don't particularly want to choose a strategy nor implement a fix yourself, then I'll do this myself. I'll probably go with option C, because: - I have not enough time and interest in cups-pdf to implement option A myself. - Option B will not fully fix the problem and you would still get the occasional bug report, which I understand you'd rather avoid entirely. Regarding "to which package should this bug be assigned to": even if this bug is assigned to package X, because that's where the chosen solution shall be implemented, it does not mean that the maintainers of package X are the ones responsible to fix the problem themselves. Other folks, who are particularly interested in the topic of the bug can help. That's how we handle things for similar topics, where a broad class of issues are fixed in a great number of packages by some specialized folks who are not the package maintainers. For example: non-systemd init support, build reproducibility, or porting to various architectures. Cheers, -- intrigeri
Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file
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=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
Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file
ke 18. syysk. 2019 klo 10.03 intrigeri (intrig...@debian.org) kirjoitti: >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. It shouldn't. This is an AppArmor issue. AppArmor interferes with CUPS-PDF configuration. Martin-Éric
Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file
This very much seems like an issue caused by AppArmor. Reassigned.
Martin-Éric
ti 17. syysk. 2019 klo 16.45 Rudolf Polzer (rudolf.pol...@i-r-p.de) kirjoitti:
>
> Package: printer-driver-cups-pdf
> Version: 3.0.1-5
> Severity: normal
>
>
>
> -- System Information:
> Debian Release: 10.0
> APT prefers stable
> APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages printer-driver-cups-pdf depends on:
> ii cups2.2.10-6
> ii cups-client 2.2.10-6
> ii ghostscript 9.27~dfsg-2
> ii libc6 2.28-10
> ii libcups22.2.10-6
> ii libpaper-utils 1.1.28
>
> printer-driver-cups-pdf recommends no packages.
>
> Versions of packages printer-driver-cups-pdf suggests:
> pn system-config-printer
>
> -- Configuration Files:
> /etc/cups/cups-pdf.conf changed:
> Out ${HOME}/Transport
> Grp lpadmin
> DecodeHexStrings 1
>
>
> -- no debconf information
>
>
> -- 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
>
Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file
Package: printer-driver-cups-pdf
Version: 3.0.1-5
Severity: normal
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages printer-driver-cups-pdf depends on:
ii cups2.2.10-6
ii cups-client 2.2.10-6
ii ghostscript 9.27~dfsg-2
ii libc6 2.28-10
ii libcups22.2.10-6
ii libpaper-utils 1.1.28
printer-driver-cups-pdf recommends no packages.
Versions of packages printer-driver-cups-pdf suggests:
pn system-config-printer
-- Configuration Files:
/etc/cups/cups-pdf.conf changed:
Out ${HOME}/Transport
Grp lpadmin
DecodeHexStrings 1
-- no debconf information
-- 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
