[Printing-architecture] Re: [printing-driver] FSG Printer Working
Group conference call 03/26/03
Robert L Krawitz
rlk at alum.mit.edu
Wed Mar 26 17:01:13 PST 2003
Date: Tue, 25 Mar 2003 23:31:44 -0500
From: Mike Sweet <mike at easysw.com>
Robert L Krawitz wrote:
> ...
> (and from the CUPS standpoint, we *will not* be supporting a
> direct scheduler<->driver interface, as that opens up serious
> security and performance issues...)
>
> What's the security issue?
The two main ones are:
1. If we directly connect to the driver/library, then any buffer
overflows in the driver/library might be exploited to gain
root access. Thus, we won't directly connect...
Yup, that makes sense. The driver should in any event run with the
least possible privilege.
2. If we indirectly connect to the driver/library, and do it
"safely" with a non-priviledged user with pipes to and from
the backend so the driver can communicate with the device,
we run the risk of a DoS attack if more than one user wants
to print at the same time and needs the "dynamic" driver
data. This also falls under the performance umbrella...
The mechanism we will be using in CUPS 1.2 is an asynchronous
device daemon with a "port monitor" facility that will allow
developers to provide printer driver filter(s) and a "port monitor"
program; the filter(s) will handle the production of data suitable
for the printer, while the (optional) port monitor handles printer
queries, data encoding, etc. One other task for the port monitor
is periodic status updates via the device monitor - this will allow
the port monitor to update the PPD file for current device
configuration, update the printer object for current state, etc.
That sounds like a good architecture anyway. I don't see why the
filter couldn't also act as an "option server" or some such, though.
Ideally we should be able to provide a GIMP-print API for
retrieving the driver constraints and/or put all of the driver-
specific data in the printers.xml file so that the driver and PPD
files are data driven and not hardcoded. This would also make it
possible for programmatic PPD file generation - CUPS would ask
GIMP-print for a list of the drivers it supports along with
"virtual" PPD filenames, and then CUPS can have GIMP-print write
the PPD file in /etc/cups/ppd as requested by the administrator.
Any suggestions from your experience what kind of constructs might be
good for this purpose?
--
Robert Krawitz <rlk at alum.mit.edu>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
More information about the Printing-architecture
mailing list