|
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 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.