× 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,

> > 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 thread ...

Replies:

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.