Rob, I would try to identify the common entry points for your application. Those will usually be menu systems, batch routing programs and several server exits. Those could adopt but adoption has all sorts of limitations with things like IFS files and triggers and can often lead to unintended exposures. I prefer to set effective group(s) for the user at those authorized common entry points. If you use this technique, you will also want to revoke authority with a registered exit or scope message that does a profile swap. Using this technique, no one without special authorities can do anything that *PUBLIC cannot do without going through your designated entry points. Those entry points need to be very well thought out and secure. Assuming that someone can likely get to a command line or equivalent somewhere, you may want to make sure users are limited capability and review commands that are allowed for those users. It is a lot of work to secure your system and I don't think anyone hits everything all of the time so journaling/auditing are important. David Morris >>> rob@xxxxxxxxx 04/26/05 9:04 AM >>> 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
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.