Bug#931363: Fails to create output PDF (permission denied)

2020-11-27 Thread Roland Hieber
I was stumbling over this today too… but a look at the code shows that the log output is confusing. On Wed, Jul 03, 2019 at 09:52:29AM +0200, martin f krafft wrote: > Wed Jul 3 09:40:55 2019 [DEBUG] output filename created: > /home/ssd/madduck/PDF/stdin___madduck_PDF.pdf Here, the output

Bug#931363: Fails to create output PDF (permission denied)

2019-09-25 Thread martin f krafft
Quoting "intrigeri", who wrote on 2019-09-18 at 08:42 Uhr +0200: Martin, could you please confirm this fixes the problem for you? Thanks for looking into this. Unfortunately, adding /home/ssd to HOMEDIRS and reloading apparmor didn't have the desired effect. I was also not aware of actually

Bug#931363: Fails to create output PDF (permission denied)

2019-09-18 Thread intrigeri
Control: tag -1 + moreinfo Hi, Brian Potkin: > I wonder whether apparmor is involved? The journal is a place to look. Indeed. It looks like Martin's $HOME directory is /home/ssd/madduck, which is not covered by AppArmor's default @{HOME} tunable ("variable"). I suspect Martin will thus see

Bug#931363: Fails to create output PDF (permission denied)

2019-07-06 Thread Brian Potkin
On Sat 06 Jul 2019 at 12:29:18 +0300, Martin-Éric Racine wrote: > I made further tests on Stretch. My current packages: > > $ dpkg -l | grep -e ghostscript -e cups-pdf | awk '{print $2, $3}' > ghostscript 9.26a~dfsg-0+deb9u3 > printer-driver-cups-pdf 2.6.1-22 > > Test 1: print an UTF-8 text

Bug#931363: Fails to create output PDF (permission denied)

2019-07-06 Thread Martin-Éric Racine
I made further tests on Stretch. My current packages: $ dpkg -l | grep -e ghostscript -e cups-pdf | awk '{print $2, $3}' ghostscript 9.26a~dfsg-0+deb9u3 printer-driver-cups-pdf 2.6.1-22 Test 1: print an UTF-8 text file from Gedit. Works. Test 2: print an ODF document from LibreOffice. Works.

Bug#931363: Fails to create output PDF (permission denied)

2019-07-03 Thread Martin-Éric Racine
ke 3. heinäk. 2019 klo 14.51 martin f krafft (madd...@debian.org) kirjoitti: > > I straced gs run directly (as user "nobody"), as well as gs run from > cupsd. After replacing all hex addresses with 0xdeadbeef, the two > traces are nigh identical, except cupsd seems to close FDs 0–2, so > that when

Bug#931363: Fails to create output PDF (permission denied)

2019-07-03 Thread martin f krafft
I straced gs run directly (as user "nobody"), as well as gs run from cupsd. After replacing all hex addresses with 0xdeadbeef, the two traces are nigh identical, except cupsd seems to close FDs 0–2, so that when run from cupsd, the first FD used is 0, whereas it's 3 otherwise. Apart from

Bug#931363: Fails to create output PDF (permission denied)

2019-07-03 Thread martin f krafft
Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 14:13 Uhr +0300: I just tried on my stable host. This used to work until a few weeks ago, but it no longer does. Can you reproduce the problem? CUPS-PDF has not been updated, but Ghostscript has received security updates twice in

Bug#931363: Fails to create output PDF (permission denied)

2019-07-03 Thread Martin-Éric Racine
ke 3. heinäk. 2019 klo 14.08 martin f krafft (madd...@debian.org) kirjoitti: > > Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 13:06 Uhr +0300: > >My best guess is that you bumped into a symptom of upgrading from > >cups-pdf 2 to cups-pdf 3. The back-end has changed and maintainer >

Bug#931363: Fails to create output PDF (permission denied)

2019-07-03 Thread martin f krafft
Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 13:06 Uhr +0300: My best guess is that you bumped into a symptom of upgrading from cups-pdf 2 to cups-pdf 3. The back-end has changed and maintainer scripts make no attempt to upgrade the backend used by any existing PDF queue. If you

Bug#931363: Fails to create output PDF (permission denied)

2019-07-03 Thread Martin-Éric Racine
ke 3. heinäk. 2019 klo 12.40 martin f krafft (madd...@debian.org) kirjoitti: > > Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 11:18 Uhr +0300: > >Is the host where this fails running a cups-pdf that was upgraded from > >previous > >releases? > > Yes, just like the other host too.

Bug#931363: Fails to create output PDF (permission denied)

2019-07-03 Thread martin f krafft
Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 11:18 Uhr +0300: Is the host where this fails running a cups-pdf that was upgraded from previous releases? Yes, just like the other host too. These are ancient systems, probably pre-sarge ;) -- .''`. martin f. krafft @martinkrafft

Bug#931363: Fails to create output PDF (permission denied)

2019-07-03 Thread Martin-Éric Racine
Hey Martin, Thanks for this bug report. Is the host where this fails running a cups-pdf that was upgraded from previous releases? Martin-Éric ke 3. heinäk. 2019 klo 11.09 martin f krafft (madd...@debian.org) kirjoitti: > Package: printer-driver-cups-pdf > Version: 3.0.1-5 > Severity: normal

Bug#931363: Fails to create output PDF (permission denied)

2019-07-03 Thread martin f krafft
Package: printer-driver-cups-pdf Version: 3.0.1-5 Severity: normal The PDF driver is failing to write the output PDFs. For example, a command like echo foo | lp -d PDF yields the following DEBUG output in the log: Wed Jul 3 09:40:55 2019 [DEBUG] *** Final Configuration *** Wed Jul 3