QUERY/400

[Guest.Visitor]

Scenario: we have a few knowledgeable users that use QUERY/400 for reports and creating databases.[*] we don't want to take away their ability to create files[*] we would like to prevent them from writing over any exisiting production file (this hasn't happened yet, but the chance is there)[*] we can't take away their authority to production files because these users are high up on the food chain and need access to these files What kind of security can we put on QUERY/400 itself? There's never time to do it right, but.....there's always time to do it over.

[Guest.Visitor]

On Wednesday, September 23, 1998, 07:09 AM, vincent wrote: Who is supposed to have the special authority (*SERVICE) in the user profile?? By default, on a new system: QSECOFR, QSYS, and QSRV. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.

[Guest.Visitor]

On Wednesday, September 23, 1998, 07:34 AM, vincent wrote: When I compile, I see the parameter as USRPRF. Where can I get the USEADPAUT parameter?? Are they the same meaning?? The two parameters have different meaning. The USRPRF(*OWNER) would effect adoption of authorities from the owning user for that invocation. The USEADPAUT(*YES) says to allow adoption of authorities from the calling program, if the calling program has USRPRF(*OWNER). CHGPGM can be used to modify a program to not use adopted authorities which could be propagated from previous invocation levels; the default being to allow it. Read the help text on the USEADPAUT parm on the CHGPGM command. I am not aware of any CRTxxxPGM commands which have this as a parameter. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.

[daly.michael@verizon.net]

Jo Ann, Could you restrict there create/update access to specific libraries that are separate from the production data they need for input? Or, could you restrict there authority on production libraries to create only, with no authority to change/update existing files? One day, we'll all be heroes.

[Guest.Visitor]

Mike; Could you restrict there create/update access to specific libraries that are separate from the production data they need for input? Or, could you restrict there authority on production libraries to create only, with no authority to change/update existing files? These are high-level users, they have their 'hands' into everything. Is there a way of just making sure they cannot replace a file they haven't created? We can't just take away their delete authority. Could we 'easily' create our own QUERY function? One day, we'll all be heroes. There's never time to do it right, but.....there's always time to do it over.

[daly.michael@verizon.net]

On Friday, September 25, 1998, 05:07 AM, Jo Ann Burelle wrote: These are high-level users, they have their 'hands' into everything. Is there a way of just making sure they cannot replace a file they haven't created? I don't know, but I don't think so. We can't just take away their delete authority. Why not? I've worked at four different shops in my brief career, and all of them had their production data libraries locked down so no one but the security officer, or a program with SECOFR authority, had object existence authority. This way, even programmers can't DBU the file and change data without asking somebody for permission. Data only gets changed by production programs. Power users still get to run queries, but their output is directed to their own libraries. The do NOT get to run queries which alters production data. Each power user gets his/her own private library, which is not part of the daily backup, but could be saved if requested. The libraries owner is the only user with object existence authority (besides the SECOFR) in his/her own library. I think this plan works great. If your "high-level users" want more authority than this, then they have to take the responsibility for when they screw something up. Wash your hands of this one. One day, we'll all be heroes.

[Guest.Visitor]

Micheal; Thanks, your idea is a good one. I'll be presenting it at our next programmer's meeting. There's never time to do it right, but.....there's always time to do it over.