Hello, On Mar 8 11:16 JP Rosevear wrote (shortened):
On Thu, 2007-03-08 at 10:57 +0100, Johannes Meixner wrote:
http://www.cups.org/str.php?L790 ------------------------------------------------------------------- the CUPS admin user can copy this way any printout to any place he likes (e.g. send it via mail to any external address ... ------------------------------------------------------------------- ... The solution though is in a comment in the upstream bug:
"If you would like to contribute a patch which adds a "RestrictFilters" option (or a list of allowed paths, or something like that), we will consider it for inclusion in CUPS 1.2."
We could be proactive here and send a patch upstream!
According to http://www.cups.org/str.php?L790 such a "RestrictFilters" option has the consequence that it "would prevent driver developers from installing in alternate locations" (in particular third party drivers). I think what might be better is to distinguish between adding and deleting queues and changing existing queues. This way the system admin could allow that normal users can add (and perhaps even delete) queues but the system admin could forbid to change existing queues. For example a travelling salesman may have a company laptop where the system admin had set up carefully some queues for the company printers which the travelling salesman should not change but the system admin may allow that the travelling salesman can set up additional queues to print to whatever external printers e.g. in an external Windows-only or iPrint-only environment where usually even drivers must be installed on the client system to set up printing. Some background information regarding Unix/Linux-like printing and Windows/iPrint-like printing in the network: The crucial design difference is: Unix/Linux print systems: The client systems send the original data (e.g. plain text, PostScript, JPEG) to the print server and the print server converts it into printer specific format (the "filtering") and sends the printer specific data to the printer. Windows-like print systems: The client systems convert the original data into the printer specific format (therefore a printer specific driver is needed) and then send the printer specific data to the print server and the print server sends the printer specific data to the printer. Consequences: Unix/Linux print systems: The client systems don't need to care about the printer model. It is only the print server which is responsible to do the model specific stuff. This is THE advantage of the design under Unix/Linux. If an end-user has a laptop and connect it to a new network where a CUPS server is running and if the end-user runs his own cupsd on his own laptop, then he can immediately print. Windows-like print systems: The client systems must care about the actual printer model. Therefore usually model specific printer drivers must be installed on the client systems. This is THE drawback of the design under Windows. If an end-user has a laptop and connect it to a new network, then usually he cannot print without doing driver installation before. Perhaps he doesn't want to download and install drivers from an unknown/untrusted network system - what should he do? Consider the problems when printers are added or exchanged: Special software stuff (provide drivers for download) and special end-user actions (driver installation/replacement) are needed to deal with this situation. For more details see my "two longer explanations" in http://lists.opensuse.org/opensuse/2004-11/msg02874.html Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org