× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


Gary Monnier | Senior Software Developer

19426 68th Ave. S
Kent, WA 98032
(253) 872-7788 ext. 308
gary.monnier@xxxxxxxxxxxxx
www.powertech.com 
This email message and any attachments are intended only for the use of
the intended recipient named above and may contain information that is
privileged and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message or by telephone and delete the
message from your email system. Thank you.




-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
Sent: Tuesday, November 16, 2004 7:18 AM
To: Midrange Systems Technical Discussion
Subject: RE: security hole in interactive sql call statement?


anybody know if there is an exit point for STRSQL?

We have a exit program for Database Server (QIBM_QZDA_*).  However,
doesn't seems like STRSQL is hitting this exit point.
 

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of CWilt@xxxxxxxxxxxx
Sent: Tuesday, November 16, 2004 8:58 AM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: security hole in interactive sql call statement?

> Is there a way to lock down call statement in STRSQL?

Don't know if an exit program exists, but if it does you could use that.

>  
> thanks
> 
> 

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.