PORTIA@engvax.UUCP (Portia 616-2635) (09/09/86)
We have a problem when users on Decnet take *advantage* of the existence
of a laser printer on another node. We would like to restrict the
copying of files to the printer over DECnet or otherwise to charge the
users properly. Does anyone have a solution?
The only things we can think of are to:
1) use proxy and get rid of the default decnet account.
2) put in some code in FAL.COM to check for the destination of the copy
any suggestions welcome, thanks in advance.
-- Portia Bjorndahl UUCP -- {allegra|ihnp4}!scgvaxd!engvax!portia
Hughes Aircraft Co. ARPA -- engvax!portia@csvax.caltech.edu
(213) 616-2635LEICHTER-JERRY@YALE.ARPA (09/20/86)
...We would like to restrict the copying of files to ... [a laser] printer
over DECnet or otherwise to charge the users properly. Does anyone have a
solution?
The only things we can think of are to:
1) use proxy and get rid of the default decnet account.
2) put in some code in FAL.COM to check for the destination of the copy
any suggestions welcome, thanks in advance.
First off, you have to decide what you are trying to accomplish: Prevent
people from using the laser printer through DECnet, or permit them but
charge them properly. It's possible to combine these to restrict usage only
to certain people.
Method 1 allows you to allow some (or all) people to use the printer via this
mechanism with proper chargeback. This is by far the most flexible solution,
since it allows you to specify on an individual basis who may and may not use
the laser printer. It has two drawbacks:
- You have to disable ALL default access to the system or people
will just specify a null account (NODE""::) and avoid the
proxy;
- You have a lot of administrative overhead maintaining all those
accounts you might otherwise have never created.
There are at least two ways for someone to print a file on a remote printer:
- Copy directly to the spooled remote device.
- Copy the file itself, then do a SUBMIT/REMOTE start up a network
task (file specification "TASK=file") to use the PRINT
command on the other system.
The first of these is very easy to block: Just don't make the device spooled!
The queues and associated commands will work just fine - all that won't work
is copying directly to the device, which will always fail to allocate the
device. There are more subtle variations: You could try putting an ACL that
blocks access from the DECnet default account on the device. I seem to remem-
ber that there were some problems with this, though. Or, spool the device to
a disk on which the DECnet default account has no quota. I do NOT advise
mucking around with FAL.COM - it's almost impossible to come up with a secure
way of blocking access this way. For example, if FAL.COM does something like
assigning NL: to LP:, the user just copies to _LP: or LP0: or LP00: or LPA0:,
etc.
The second access method is easy to block: Disable the TASK object. This has
some unfortunate side-effects, however - there are legitimate uses for the
TASK object.
-- Jerry
-------carl@CITHEX.CALTECH.EDU (Carl J Lydick) (09/21/86)
You're right that there are problems with setting an ACL on the print device to control printing from remote nodes: it doesn't work, since a file copied to the device (if it is spooled), is printed by the symbiont, typically owned by SYSTEM. There may be problems with setting the device /NOSPOOLED: some years ago, for example, I tried doing that with a Versatec printer using a Versatec-supplied symbiont, and the result was loss of portions of plotted files queued to the device; while this indicates (I think) a bit of sloppiness in the code for the symbiont, it IS a gotcha that shouldn't be ignored.