Bill Sommerfeld wrote:
> On Thu, 2007-08-30 at 10:34 +0100, Darren J Moffat wrote:
>
>> I'm not sure that secure-by-default does require that this be off. As I
>> understand this case it is egress probing not a daemon listening of
>> ingress requests.
>>
>
> So we're ok at the transport layer, but I think we also need an
> application-layer analysis.
>
> At least some of what people send to printers tends to be sensitive.
> So one critical question for a SbD analysis is how
> automatically-discovered printers turn into usable destinations for
> print jobs. So long as there is a administrative step needed to "move"
> a printer from a "I hear it's out there somewhere" to a "ready to print"
> state I think we're most of the way there.
>
There is. The printers are discovered and placed in the HAL device
tree. From there, there is a desktop applet that looks for changes to
the HAL device tree and prompts the user to create a queue. If you are
running build 69 or later and plug in a USB printer you will get the
idea. Or you can take a look at
http://www.opensolaris.org/os/project/presto/Movie/
> (and as a largely unrelated gripe, maybe I'm missing the trick but it
> seems like it would be clever to be able to configure a user account or
> system so that printers listed in NIS or LDAP were merely "out there" so
> that gui print menus wouldn't take forever to enumerate printers before
> putting up an unusably long list).
>
You can limit the current list of queues by adding an "_all" entry to
${HOME}/.printers, but that may not be ideal for everyone. As a result,
we are looking at putting forth a separate case to deal with advertising
and discovering print queues so that you get more reasonable (and
relevant) lists of available queues than the 5000 queues in the name
service.
-Norm
