enterprise-ubuntu team mailing list archive

[Bolesław Tokarski <boleslaw.tokarski@xxxxxxxxx>]

Hello,

The way we offer printers to our users is that we have implemented a
simple GTK-based application that searches AD's LDAP and prints the
printer name along with its location. Although most of the printers
publish some kind of information on the driver required, I wouldn't say
it is totally reliable. However, most of our printers seem to support
PostScript, so we are using that one. For printing backend we used a
shell wrapper, ksmb, which accesses Samba printers using Kerberos.

Now, restrictions on colour printing is a tough thing. The printers we
use provide this functionality in their Windows drivers, so that a
printer queue in AD is set to use driver providing colour or not.
Additionally, there's a group policy enforcing that you cannot use a
different driver (allowing colour) on a printer queue that should not
have access to colour printing on device. The truth is, however, that
once you use a Linux printing driver, no such restrictions are in place
and you can print colour images to a non-colour printing queue.

A real colour printing restriction would need to be put on the print
server side, I believe. You can't trust the client to generate a raw
binary string that will not ask the printer to use colour, the same way
you can't tell if the data stream is supposed to print colour or b&w,
unless you knew the logic of the printer and could parse the stream.

However, in the Linux world you have much more flexibility. The printing
'drivers' are actually simple programs (filters) that parse stuff on
input and produce printer-consumable output. You can use them on the
print server (though it's rarely used), on the clients you would need to
be able to get the data to the printer in some unmodified raw format
directly from software, or perhaps in a universal PostScript code that
your server-side driver would be able to parse. It might be non-trivial,
but I believe that's the only way to enforce b&w printing.

Oh, there's another way - have a separate printer for colour printing
that you deny access to to anyone who should not print colour.

Regarding the CUPS bug you mention, I'd recommend you tried this on a
newer Ubuntu. If the bug has been fixed, you should be able to backport
it or narrow down the bug report to a specific version of CUPS.

Cheers,
Ballock



On 05/09/13 18:26, David Burke wrote:
> Hello,
>
> I'm wondering how others deal with printing in Ubuntu. I use a
> centralized CUPS server so that all printers just show up for users.
> What I want is
>
> - Easy for end users (no driver installation)
> - Allow or block access to certain users and groups
>
> CUPS has this functionality built in, but it's broken in 12.04. 
> When unauthorized to print, clients effectively DOS attack cups server
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689991>
> No notice of permission issue or chance to provide credentials to
> print <https://bugs.launchpad.net/ubuntu/+source/cups/+bug/989852>
>
> Does anyone have a solution? Samba perhaps? Am I the only person in
> the world encountering these issues? In the meantime I've just removed
> all access restrictions but it's not ideal in a school environment
> where students shouldn't be printing color images of cats, etc.
>
> Best,
> David Burke
>
>