[2493] in Enterprise Print Delivery Team
Problems Saving Unauthorized LPR Jobs to Restricted IPM Queues
daemon@ATHENA.MIT.EDU (Rocklyn E. Clarke)
Thu May 30 14:32:49 2002
Mime-Version: 1.0
Message-Id: <p05010403b91c1aa2f91e@[192.168.1.102]>
In-Reply-To: <200205212132.RAA05018@riff-raff.mit.edu>
Date: Thu, 30 May 2002 14:32:46 -0400
To: Enterprise Printing Delivery Team <PRINTDEL@MIT.EDU>
From: "Rocklyn E. Clarke" <rclarke@MIT.EDU>
Cc: IPM-SYS <IPM-SYS@MITVMA.MIT.EDU>, "Regan,Theresa M" <tregan@MIT.EDU>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Hi Team,
As you know, we plan to automatically download Moira printcap
information to LPRng running on the IPM servers. We would also like
to make use of LPRng's ability to restrict selected print queues so
that only authorized job users can submit jobs through them.
Furthermore, we have a business requirement that a job submitted to a
restricted queue by an unauthorized user be saved in case the job is
one that really should be printed.
Last week I raised a concern with this plan based on my understanding
of LPRng which Garry has now confirmed (see his email below). If we
attempt to download from Moira a list of authorized users for a print
queue, LPRng will reject lpr submissions from unauthorized users
WITHOUT giving us a chance to grab the print job and save it anywhere.
In order to implement restricted queues, we would need to download a
list of authorized users to a non-standard file (i.e. NOT
/etc/lpd.perms) and IMPLEMENT OUR OWN LOGIC for checking ALL lpr jobs
for ANY print queue against a new internal list of restricted queues
and authorized users.
Obviously this is would be a significant departure from our strategy
of paralleling as much as possible the structure of the Athena Print
Services implementation. It would also create more potential points
of failure for our printer service. There may very well be a way to
save print jobs from unauthorized users without incurring these
disadvantages, but nothing elegant springs immediately to mind for
me. I'm willing to give this some more thought, but since I don't
have as much time to devote to this as I used to, I want to give
everyone else out there a chance to come up with something.
Rocklyn
P.S. Something inelegant: It occurs to me that we could "front-end"
a restricted queue with an unrestricted queue and "trap" rejected
jobs in the middle. This would add an unfortunate amount of
complexity, but perhaps it would work. I'll let Garry weigh in on it.
At 5:32 PM -0400 5/21/02, Garry Zacheiss wrote:
> >> Do you have any alternatives to suggest?
>
> No; if you want this feature, you'll need to implement your
>authorization in the filter.
>
>Garry
