|
Lim, > > if I set the user profile to LMTCPB(*YES), the profile should not be able > to access any limited command from any ibm tool. > > The limit capabilities option only works for function that goes through the > command analyzer. The SQL CALL command in STRSQL is not a CL command. > > If you do have object authority in place on the programs that a developer > might call from the SQL CALL command in STRSQL, I think they would be > prevented from calling that program. In addition, if the called program > attempts to manipulate data that the programmer is not authorized to, the > program will not complete successfully (assuming that the program doesn't > adopt authority). > > My point in all of this, is that relying on LMTCPB(*YES) as your only > access control mechanism for data or programs provides very little > security. I am sending this to add a little to what Pat said above. The purpose of LMTCPB(*YES) is to prevent the use of most CL commands (those with ALWLMTUSR(*NO) specified) from being used on a CL command line. Those commands can still be used from a menu and from a CL program. The STRSQL command does not display a CL command line and as far as I can tell, it does not allow the use of any CL commands. It does allow the use of SQL statements. The CALL SQL statement is not the same thing as the CALL CL command. Internally both CALLs end up in the same place and that is what allows them to call a program. Each language has its own CALL statement and none of them are restricted by a LMTCPB(*YES) user. When the STRSQL command is shipped it has ALWLMTUSR(*NO) specified. So for a LMTCPB(*YES) user to be able to use the STRSQL command, someone else had to allow them to use it. Ways to do that include changing the command to ALWLMTUSR(*YES), adding it to a menu, and placing it in a CL program that the user can reach from a menu. Because of the function of the CALL SQL statement, from a security point of view, allowing a LMTCPB(*YES) user to used STRSQL is about the same as changing the CALL CL command to ALWLMTUSR(*YES). My point is that when you rely on limited capabilities for your security you must be very careful on what interfaces you allow your users to use. Ed Fishel, edfishel@xxxxxxxxxx
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.