|
It's still an open access method. For a number of reasons. In Patrick's article (always eloquent) he stated that most shops allow people access to the data except the data they want to control. That is an open shop. A closed shop would change system value QCRTAUT to *EXCLUDE and then only let them access to data they wanted them to have. Another thing that makes it an open system, in my mind, is that your method would still allow the users to UPDDTA, etc the files in question. It would also allow them to ftp the data, etc. Pat mentioned that you could use exit points to restrict this, but ideally you would not let them have access to the data, as a default, in the first place. One method is to only allow access via programs that adopt authority. This way the users have no direct access to the data itself. We found that our canned package has every program set to USEADPAUT(*YES). All we would have to do is to change the initial program to be owned by a user with access to the data. The only problem with this package is there are too many points where the users are given a command line via CALL QCMD or QUSCMDLN and the thought of doing CHGPGM USEADPAUT(*NO) on these two hasn't been totally worked through yet. This would effectively lock out all access via other tools, interfaces, etc for these users. And now that the thought of changing QCMD and QUSCMDLN just hit me, it bears another round of internal discussion. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Wilt, Charles" <CWilt@xxxxxxxxxxxx> Sent by: security400-bounces@xxxxxxxxxxxx 04/26/2005 07:25 AM Please respond to Security Administration on the AS400 / iSeries <security400@xxxxxxxxxxxx> To "Security Administration on the AS400 / iSeries" <security400@xxxxxxxxxxxx> cc Subject RE: [Security400] RE: Prevent User Profile from using public authority > -----Original Message----- > From: security400-bounces@xxxxxxxxxxxx > [mailto:security400-bounces@xxxxxxxxxxxx]On Behalf Of Patrick Botz > Sent: Monday, April 25, 2005 7:41 PM > To: Security Administration on the AS400 / iSeries > Subject: Re: [Security400] RE: Prevent User Profile from using public > authority > > > In my opinion, exit point products, while providing a very > large amount of > value add, are NOT a replacement for an exclusionary access > control model. > > An exclusionary model defaults PUBLIC authority to *EXCLUDE > -- i.e. access > is excluded to PUBLIC by default unless and until explicitly > configured > otherwise. PUBLIC authority of *USE or greater is still > appropriate for > some data in this model, but it is not assumed to be the > desired access. > > An open access control model assumes everyone should be > allowed *READ or > higher access to everything unless explicitly configured otherwise. > Because of the heritage of i5OS many, if not most, customers > have an open > access control model. > Patrick, I'm pretty much in agreement with you. Looking back at my original post and the two options I outlined: 1) a. Create a group profile for all my "regular" users. b. Grant the group profile the same authority that *PUBLIC currently has for each & every object c. change *PUBLIC to *EXCLUDE for every object 2) a. Grant *EXCLUDE authority to every object for this user profile (or better yet a new group profile of which this profile will be a member) Would you agree that #1 is exclusionary and #2 is open? So you recommend #1? If so, how do I go about getting it implemented? Is the "Tips & Tricks" book still the best resource? What about IBM objects? Will option #61 "Revoke public authority to objects" on the SECTOOLS menu take care of everything or will I need to worry about other IBM objects? Thanks, Charles Wilt iSeries Systems Administrator / Developer Mitsubishi Electric Automotive America ph: 513-573-4343 fax: 513-398-1121 _______________________________________________ This is the Security Administration on the AS400 / iSeries (Security400) mailing list To post a message email: Security400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/security400 or email: Security400-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/security400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.