× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: FTP question
  • From: Rob Berendt <rob@xxxxxxxxx>
  • Date: Wed, 1 Mar 2000 17:08:46 -0500

I love the one package that we installed.  One program that 
adopted QSECOFR authority had one line of CL in it.
CALL QCMD
Made it easy for them to talk trusted users into fixing things 
for them.  Of course I wanted to string them up certain parts 
of their anatomy.





rjs@pgsas400.com on 03/01/2000 05:02:07 PM
Please respond to MIDRANGE-L@midrange.com@Internet
To:     MIDRANGE-L@midrange.com@Internet
cc:      
Fax to: 
Subject:        Re: FTP question

Hey Ken,

Agree: Object Level Authority reigns supreme on the 400. An undisputable 
fact!!!!

Question: What percentage of AS/400 shops implement Object Level Authority?

Join the real world, not very many.....

And yes Ken, FTP has been around a long time as a widely used tool, no big 
secret. However, the
average user at an average company, with average security, will not know about 
FTP and its
potential.

Concerning OBJ AUTH:

Libraries with PUBLIC(*EXCLUDE) will, by default, keep EVERYBODY out of the
AS/400 library file system. In order to make the system usable individual users
will need to be given specific authority to the libraries, (and objects within
them) they need to do their job. If the system isn't opened up in this way
nobody will be able to use it.

Individual programs can run in two ways.
1. Under the user profile of the owner, or
2. Under the user profile of the end user.

If the program runs with USRPRF(*OWNER) then any user of that program will have
the same level of access to objects on the system as the owner of the program.
For example, if user JSOAP runs program ABC owned by QSECOFR and that program
runs with USRPRF(*OWNER), then JSOAP will have QSECOFR access to the objects
used by that program. JSOAP will not have QSECOFR access any other object on the
system and JSOAP will only have QSECOFR access to the objects used by program
ABC when he is using ABC. Hence if ABC uses file XYZ to produce a report and
JSOAP has been granted access to program ABC, then JSOAP will be able to obtain
that report even if JSOAP does not have specific authority to file XYZ.

If, however, program ABC runs under USRPRF(*USER) then JSOAP will not be given
any special authorities and a Not Authorized to File XYZ will be issued when he
tries to run program ABC.

In an ideal system, all programs should be compiled USRPRF(*OWNER) and end users
should have authority to nothing. other than the programs they use. This ideal
system is not always possible or practical.

People need authority to objects in order to do their job. The above scenario
only works for green screen applications, prevents the direct use of query, SQL,
FTP, ODBC, or any other function that requires direct access to the
database.

There is also the question of the non-library IFS. Files in this part of the
system are not accessed via green screen options, so individual users must have
direct access to the objects they use.

After a user has been given access to an object, operating system security
cannot control how that object is accessed. Operating system security merely
checks that the user is authorized.

I hope we have all learned something from this thread. I have.

Richard J. Serrano


----- Original Message -----
From: Sims, Ken <KSIMS@SOUTHERNWINE.com>
To: <MIDRANGE-L@midrange.com>
Sent: Wednesday, March 01, 2000 9:14 AM
Subject: Re: FTP question


> Hi Richard -
>
> >Date: Tue, 29 Feb 2000 17:06:47 -0800
> >From: "Richard J. Serrano" <rjs@pgsas400.com>
> >Subject: Re: FTP question
> >
> >Agreed: It does take a valid user id & password to log onto the
> >AS/400 through FTP. BUT, when 86% of theft or misuse of data is
> >attributed to the "authorized user" with a valid user id & password,
> >they are more of a security threat than anyone cares to admit.
>
> Well, let's make it simple.  Just disable all of the profiles on the system.
> Then you'll be  safe.
>
> Join the real world.  FTP is a standard protocol that's been around for
> years and years and years.  Mentioning in an email list that a standard FTP
> client can be used to access an AS/400 is not giving away any big secret.
>
> >Disagree: Appropriate object authority to the file(s) being accessed is
> needed.
> >Using FTP, an authorized user has unabated access to ALL objects on the
> AS/400.
> >Try it. Set up a test profile, with a valid user id & password, but grant
> NO
> >authority to anything on the 400.
> >Then, use FTP through DOS, as outlined, and see what happens... Access to
> the
> >whole enchilada...
>
> I logged on to my AS/400 through FTP from my PC and tried to access a file
> that I know that profile should not have access to.  I got the following
> message ...
> 550 Not authorized to file QAUDJ00090 in library KSLIB.
> That's copied and pasted exactly from the FTP client window.  So I don't see
> the problem.
>
> Ken
> Southern Wine and Spirits of Nevada, Inc.
> Opinions expressed are my own and do not necessarily represent the views of
> my employer or anyone in their right mind.
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.