|
Jeff, ODBC requests from the Client Access (or iSeries Access) ODBC drivers are processes through the *SQLSRV server. There are two exit points for this server, QIBM_QZDA_SQL1 and QIBM_QZDA_SQL2. This information used to be kept in the "Host Servers Guide", but if you Google QIBM_QZDA_SQL2 site:ibm.com, you'll find the current references. The SQL1 exit point only presents the first 512 bytes of the ODBC request to the exit program, and for this reason it is strongly not recommended. The SQL2 exit point will present the entire SQL string (up to 64K length) to the exit program. This is the exit program you should monitor because it will not allow someone to hide a file name from you in bytes 513 - 65535. Teasing a file and library name out of one of these strings (and especially doing it with any semblance of performance) is yet another trick. Remember that an SQL string can start with a "SELECT" statement and then have embedded "UPDATE" and "DELETE" statements. There is also the issue with file overrides, alias' etc. You want to be sure that you understand the potential of SQL as you write an SQL exit program. And remember that when you install exit programs into an exit point, all ODBC attempts system wide will be intercepted - so it's usually better to either have a test system that you can dedicate to this, or do your testing off hours when you won't disrupt production. And one more word of caution, remember that ODBC is only one of the many ways that users can access iSeries data from their PC's. You should also consider protecting the FTP, DDM, REXEC, and other exit programs. For that reason you may find it beneficial to purchase exit programs rather than attempt to create your own. PowerTech has been selling exit programs commercially since 1997, and we've gotten pretty good at it. I'll bet we could save you a ton of headaches. jte -- John Earl | Chief Technology Officer The PowerTech Group 19426 68th Ave. S Seattle, WA 98032 (253) 872-7788 ext. 302 john.earl@xxxxxxxxxxxxx www.powertech.com This email message and any attachments are intended only for the use of the intended recipients 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. -- > -----Original Message----- > From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l- > bounces@xxxxxxxxxxxx] On Behalf Of Jeffrey Young > Sent: Tuesday, April 05, 2005 7:53 AM > To: midrange-l@xxxxxxxxxxxx > Subject: Control access to files requested via ODBC > > I am looking for a method for restricting access to files > requested by PC users. > I would like to intercept the request and based on the > User Id, Library and File, have a program determin if the > user is allowed to access it. > Due to the nature of the PC users, it would not be > pratical to use normal AS/400 security. > I was thinking of an Exit Point program, but do not know > what Exit Point to use, or what info would be available. > > Jeff Young > Sr. Project Manager > Dynax Solutions, Inc > IBM e(logo)server Certified Systems Expert - iSeries > Technical Solutions V5R2 > > > > > > --------------------------------- > Do you Yahoo!? > Better first dates. More second dates. Yahoo! Personals > -- > 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 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.