|
On Jul 17, 2021, at 5:09 PM, Rob Berendt <rob@xxxxxxxxx> wrote:
I understand what you are saying, however what the OP is trying is "application only access" where the user has no direct access to the data. The only way they can access the data is from the applications. The goal is to keep the user away from any capability to call the programs outside of acceptable methods, such as a menu system. Such applications can be coded so that only authorized users can access certain programs. There are numerous methods of doing this.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of smith5646midrange@xxxxxxxxx
Sent: Saturday, July 17, 2021 12:52 PM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Question on Object Authority
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Unless something has changed that I am not aware of...
Since the program is owned by a super-user and is *OWNER, it does not matter
what authority the profile has, the program authority trumps the user
authority.
The only reason I can think of for revoking authority with the auth list is
to prevent DBU, SQL, etc. updates.
As a side note, having every program set up as super user and *owner is a
BAD way to have your system secured. That means that you can't really
secure any of the files and anybody that can run a program can do anything
that the program will allow them. For example, if you have a payables
system and the payables programs adopt authority as you have stated, if I
can run the payables programs, you can't stop me from updating the payables
data and cutting a payables check for myself.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Vinay
Gavankar
Sent: Saturday, July 17, 2021 11:04 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Question on Object Authority
Hi,
In our shop ALL programs in production are compiled with a "super-user" as
owner and User Profile = *OWNER ; Use adopted authority = *YES. Even all
files are owned by the same super-user.
I have a batch job running with a normal user profile. One of my files has
an Authorization List setup which has specific authority for this user which
gives only Read and Execute data rights. Super-User has all rights to the
file.
I was thinking that the batch job would not be able to add/update data to
this file. But the batch job is calling another program which is adding
records to this file.
I am not trying to stop this program from writing, but trying to understand
why it allows the write.
Is it because the write is being done by the external program running under
adopted authority of the super-user?
Would the write be allowed even if it was being done within the batch job
itself?
And if the answer to the above is Yes, I am wondering what is being achieved
by revoking the Authority in the Authorization List.
This is a big shop where us low-level programmers cannot play with Authority
Lists even on Dev box. And on the Dev box, all users have all authorities to
all files. So I cannot really test this on the Dev box.
I am planning on creating another job being run with the normal profile
which will add records to the file using a Service Program (which is also
under super-user). I just want to be sure that it will not have issues in
production.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.