[2508] in Enterprise Print Delivery Team
Fwd: Problems Saving Unauthorized LPR Jobs to Restricted IPM
daemon@ATHENA.MIT.EDU (Theresa M Regan)
Mon Jun 17 05:51:41 2002
Message-Id: <5.0.2.1.2.20020617050939.02fdf1e8@hesiod>
Date: Mon, 17 Jun 2002 05:48:25 -0400
To: lambert@MIT.EDU
From: Theresa M Regan <tregan@MIT.EDU>
Cc: tregan@MIT.EDU, IPM-SYS <IPM-SYS@MITVMA.MIT.EDU>, printdel@MIT.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Dave,
Thank-you for pointing out this e-mail and the clarification that Rockyln
and Garry have provided with regard to the relationship between "moira" and
LPRng.
For the "restricted" queues that I am aware of, there is an additional
precaution/complexity since there is application level access control, as
well. Very few people are allowed/expected to run these types of jobs
which generate print requests for these queues. I am confident that the
all the critical relationships could be set-up accurately (initially). It
is the on-going maintenance that is a concern.
Is the solution a "non-technical" solution?
For now, the restricted queue that I am aware of is the GL Statements. Do
we go forward with the implementation and the risk that GL statements will
be rejected if the userid in not in the acl in "moira"? Do we
clarify/emphasize to the business owners (Gill Emmons) and R3-admin that
when anyone in addition to Gill, Jay Nickerson, etc. are granted
authorizations to execute the GL Statements, they need to be on the moira
acl for that queue, as well. If they are not, their print job will be
rejected and need to be re-run? (This print job is too large to leave it
on the R3 servers for 48 hours which may be a solution in other scenarios.)
Or, accept that if a print job hits the GL Statement queue, it is expected
to be printed. For the operators, by chance, are there additional relevant
pieces of data which could be captured from the originating print request
for a decision to print or not. Example: generally, we know when to
expect the statements. If a print request arrives in the queue and it is
not expected, a set of procedures is followed? If we are expecting a print
job and it arrives on-time, there may be still a few other details possibly
to check out... verification that the print request originated from SAP R/3.
Sorry, I have not been able to come up with other ideas or simpler
ones. One of the challenges with the proposed restricted queues and that
we anticipate their maintenance to be infrequent. If the business
applications tied to restricted queues experienced frequent changes in
personnel, there would be less of a risk of just rejecting the print
request and the business owner would be fully aware of the impact of the
decision and coordination of the data.
Thanks,
Theresa
>Date: Thu, 30 May 2002 14:32:46 -0400
>To: Enterprise Printing Delivery Team <PRINTDEL@mit.edu>
>From: "Rocklyn E. Clarke" <rclarke@MIT.EDU>
>Subject: Problems Saving Unauthorized LPR Jobs to Restricted IPM Queues
>Cc: IPM-SYS <IPM-SYS@MITVMA.MIT.EDU>, "Regan,Theresa M" <tregan@mit.edu>
>
>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
