|
which is where it fell short. Remember, my objective is to allow programmer to STRSQL. Programmer has only view access to data files, updating or changing data is not a concerned. Oh, well, we would just have to take strsql away from programmer for now. Thanks for everybody's input. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Gary Monnier Sent: Tuesday, November 16, 2004 2:32 PM To: Midrange Systems Technical Discussion Subject: RE: security hole in interactive sql call statement? Lim, By the time you get to the STRSQL command you are inside the network as far as QZDASOINIT is concerned. This means IBM's exit points for SQL aren't invoked. It sounds like you are trying to do some object level security and application functionality at the same time. If you're concerned about users gaining the equivalent of command line access you want to limit their ability to access that functionality not their authority to specific objects, correct? In the case of STRSQL to restrict a function's availability you're out of luck. You will have to write your own version of STRSQL to do so. You can, however, limit those who can use the STRSQL command. You can do this by assigning object level authority to command STRSQL or use some other mechanism. If you don't want to assign authorities directly to STRSQL (either directly to the object or via an authorization list) you can use PowerLock NetworkSecurity's generic exit point. All you have to do is write a program that checks our generic exit point before it executes the STRSQL command. All rule set up is done within NetworkSecurity. If the generic exit point does not return an allow code then don't allow the user access to STRSQL. Otherwise go ahead and let the user execute STRSQL. If you decide to write your own version of STRSQL you can use PowerLock NetworkSecurity's generic exit point to restrict functionality for a given user.
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.