RE: Giving users "deposit" access to an output queue.

Rob,

I think you're kind of stuck, by definition, the owner of an object (spool file) can do whatever
he/she wants to do with that object.

How about changing SBMFAX to duplicate the spool file into the FAX outq with another owner? (Google
for ways to duplicate the spool file)

Alternately, how about getting with the vendor of the fax software (IBM) to modify their end to handle
a user deleting the spool file mid-process? It seems to me that the problem could be seen as a bug.

Charles Wilt
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307

wiltc@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, March 27, 2008 8:26 AM
To: Midrange Systems Technical Discussion
Subject: Re: Giving users "deposit" access to an output queue.

I was really hoping to not have to change all programs that use SBMFAX to
change the overrides on the spool file.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





CRPence <crp@xxxxxxxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/26/2008 08:43 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
midrange-l@xxxxxxxxxxxx
cc

Subject
Re: Giving users "deposit" access to an output queue.






I do not think you want *DTAAUT; perhaps AUTCHK(*OWNER).?
?CHGOUTQ
Authority to check (AUTCHK) - Help
*DTAAUT
Any user with add, read, and delete
authority to the output queue can
control all spooled files on the queue.

AFaIK the DLTSPLF does not care about in which OUTQ the spool file
resides if it is the owner of the spool file requesting the delete; i.e.
the user that owns the spool can always delete? Pg434 v5r4: Note 1 in
the Security Reference for "Spool Commands", DLTSPLF, "Users are always
authorized to control their own spooled files."

If the spool file is created to an alternate owner [see SPLFOWN() in
OVRPRTF for example], then the user would not be able to modify\delete
the spool given the OUTQ has OPRCTL(*NO) and/or the user has no special
authorities to control job\spool... where controls are limited to the
*OWNER of the queue and/or file.

Regards, Chuck
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer

rob@xxxxxxxxx wrote:

I want users to be able to put any spool file into a particular
output queue. However, once it is there, they cannot delete it, etc.
They're interfering with FAX/400.

I tried creating the output queue with AUTCHK(*DTAAUT) and making
*PUBLIC *USE however they could still delete the spool file. If I
make it *EXCLUDE they cannot deposit. So I left it *EXCLUDE and
they could do a SBMFAX and that process (running under a different
profile) would then put it into that output queue. However, they
could still delete the spool file while it was in that output queue.

I have "Display any file" set to *NO.

With this authority they cannot display or delete other spool files
on that output queue, however they can still abuse their own and I'd
like to stop that.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.