|
midrange.com
PLEASE NOTE : No sarcasm is intended, however, I know that sarcasm WILL be
projected from my response to this.
Lets take this from the sublime to the WAY ridiculous.
Somebody requires access to High level Top secret documents, but to obtain this
data "they then have to jump through all sorts of hoops."
So lets make it easier to obtain this data. Oh, did'nt they do that at some
military installation in California just recently.
Sarcasm switch now turned off.
Implementing a security procedure is NOT easy, and it is (or should be) ALWAYS
revised. If it is hard for a person to be able to obtain data, then surely the
security is working.
Letting an application handle the security (even if users only see the options
they need to see) is NOT (this is strictly my opinion) the procedure to use. If
fred Bloggs should never have access to the payroll master file, then the
security should be in place that he is NOT allowed access, even through the
application, thet he may or may not have. If he should have access to the
payroll master file, give him direct access. If not, he falls into the category
of PUBLIC *EXCLUDE.
>>> <rob@dekko.com> 07/27/01 11:10AM >>>
But, Alan, most of the geezers are very comfortable with 5250 menu
security. They've created fancy menus that are customized to the user.
Certain users only have certain options. People who should not withdraw
funds cannot. This technique used to be valid until the arrival of the
S/36 and the S/38. When these machines came along alternative methods of
access came into being, one of the early ones being Client Access. Now
that we have Client Access, ftp, odbc, etc., then the recommended way of
securing things so that your menu system has any validity at all is to
allow no access to data except via adopted programs.
The other alternative is to either purchase a package to handle all exit
point programs, or write your own. Of course, with IBM adding new exit
points with every release, we went with the package option.
Of course, when one DOES want to access a file with Client Access, or
whatnot, and has a valid business reason for doing so, they then have to
jump through all sorts of hoops.
Rob Berendt
==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.
"alan shore"
<SHOREA@dime.com> To: <RPG400-L@midrange.com>
Sent by: cc:
owner-rpg400-l@mi Subject: RE: Programing
Question/Authority...
drange.com
07/27/2001 08:38
AM
Please respond to
RPG400-L
I have been VERY cautious in taking this approach, as this means that
ANYBODY that can sign onto the system can really play havoc with the system
JUST by using the application.
Fred Blogs has a valid profile/password to sign onto the system, and even
with NO command line can apply payments, withdraw funds, place orders etc.
just by following the menu options, because there is NO security to stop
him due to the application giving him the authority because he is signed
on.
Whereas, if authorization per Group profile or user profile was applied to
the files within the production libraries, the security would stop him
because he is NOT authorized to update a particular master file. He is only
allowed to read the master file.
Using adopted owner authority should be used ONLY where needed, NOT across
the gamut of the application.
But then thats just my opinion, for what its worth.
>>> "Njal Fisketjon" <n.f@figu.no> 07/26/01 08:43PM >>>
I am a bit surprised to see all the postings regarding USRPRF(*OWNER)
I always thought this was the recommended way of handling db security:
- use public *Exclude on all libraries
- let each application (all programs and files) be owned by an owner
profile with pwd *none
- use USRPRF(*OWNER) on all application programs
Something important must have slipped by me if this is no longer a
recommended approach.
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@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.
