Subject: Strange, subtle papd/printing problem

From: Peter Gutowski <[email-masked]>
Date: 28 Jun 2000 13:48:57 -0400

I'm having problems trying to setup up printing on one of my Linux machines. The annoying thing about this is that I have an "identical" setup on my machine at home. For reasons perhaps only unix gurus can (hopefully!) explain, printing to the Linux machine using papd works at home, but not at work.

Here's some info:

Version Info:

Redhat 6.1 on Packard-Hell 133mhz, netatalk-1.4b2+asun2.1.4 (b.37 I think)

- - - - - - -/usr/local/atalk/etc/papd.conf - - - - - - -

GhostScript to D800:\
        :pr=tiff:\
        :op=lp:\
        :pd=/usr/local/lib/ppd/ghostscript.ppd:

- - - - - - - portion of /etc/printcap - - - - - - - - -

tiff:\
        :sd=/var/spool/lpd/tiff:\
        :mx#0:\
        :sh:\
        :lp=/var/spool/lpd/tiff/null:\
        :if=/var/spool/lpd/tiff/tifffilt:

I can print from my Mac to the Printer called "GhostScript to D800". No errors or problems. I can also print using lpr from the command line. The problem I seem to have is that something about the permissions on the file in the spool folder generated by papd seem to have the wrong owner or permissions. Here's what I mean:

If I turn of the printer called "tiff" by doing a 'lpc stop tiff' and print to the printer here's what I get in the spool folder (print a file from the Mac; then print the same file to disk then add it to the queue from the command line.

This accomplished, here's what's in the spool folder:

/var/spool/lpd/tiff:
-rw-r-----   1 root     root          209 Jun 28 13:21 cfA031lx1.powervue.com
-rw-rw----   1 bin      lp            129 Jun 28 13:22 cfA032lx1.powervue.com
-rw-r-----   1 root     root       526691 Jun 28 13:21 dfA031lx1.powervue.com
-rw-rw----   1 peterg   lp         526691 Jun 28 13:22 dfA032lx1.powervue.com
-rwxr--r--   1 lp       root           28 Jun 28 13:05 lock
crw-rw-rw-   1 lp       root       1,   3 Jun 26 15:26 null
-rw-rw-r--   1 root     root           18 Jun 28 13:21 status
lrwxrwxrwx   1 root     root           40 Jun 26 15:28 tifffilt -> /usr/lo....

Note the difference in permissions above: the file printed from the command line is 660 but the one spooled from papd is 640. Note ownership as well.

If I turn "on" printing with 'lpc start tiff' here's what I get in /var/log/messages

Jun 28 13:28:38 lx1 lpd[1854]: tiff: job could not be printed (cfA031lx1.powervue.com)
Jun 28 13:28:38 lx1 psf[1862]: starting for ?
Jun 28 13:28:38 lx1 psf[1862]: PostScript
Jun 28 13:28:41 lx1 psf[1862]: done

The other file ("cfA032lx1.powervue.com") printed (ripped) correctly. Now, as a "interesting" sidelight, if (as root) I change the permissions on the file from 640 to 666 the file processes correctly with no messages in the log. Now I know that papd starts as root, but somehow expect that the "op=lp" line in the papd.conf file would have it do a setuid() to 'lp' before spooling the file. If I jump to the src directory etc/papd and do a 'grep [ug]id *.c *.h', it yields nothing. How is the "op=" parameter used?

As I said, the home system works OK and to my surprize has the same permissions situation from papd, but for some reason doesn't generate and error. Any ideas or recommendations thankfully appreciated!!!

-Peter Gutowski

---

From: andrew morgan <[email-masked]>
Date: Wed, 28 Jun 2000 11:22:18 -0700 (PDT)

On 28 Jun 2000, Peter Gutowski wrote:

> I'm having problems trying to setup up printing on one of my Linux
> machines. The annoying thing about this is that I have an "identical"
> setup on my machine at home. For reasons perhaps only unix gurus can
> (hopefully!) explain, printing to the Linux machine using papd works
> at home, but not at work.
> 
> Here's some info:
> 
> Version Info:
> 
> I can print from my Mac to the Printer called "GhostScript to D800".
> No errors or problems. I can also print using lpr from the command
> line. The problem I seem to have is that something about the
> permissions on the file in the spool folder generated by papd seem to
> have the wrong owner or permissions. Here's what I mean:

>From what I can see in the papd code, it never tries to set the
owner/group of the file with the op setting.  It uses op to set some
options in the lpr control file, like so:

lp.c:       fprintf( cfile, "P%s\n", printer->p_operator );
lp.c:       fprintf( cfile, "L%s\n", printer->p_operator );

printer->p_operator holds the value of op from the config file.

I would highly recommend that you pipe the output to lpr instead of
letting papd meddle in the spool directory itself.  You'll avoid all these
permissions problems.  In your papd.conf file, change ":pr=tiff:\" to
":pr=|/usr/bin/lpr -Ptiff:\".

	Andy