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&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
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