🚀 go-pugleaf

Laurence Chiu (lchiu@crl.com) wrote:
[...]
>In the C/S world as I understand it, if a user signs onto to the
>database and then runs an application, that user has to be
>explicitly given the access rights the application needs (read,
>write, update etc.) so there is no theoretical reason why that user
>could not use some query tool to retrieve or update records outside
>of the application. I am discounting stored procedures here - would
>they make a difference?

You are correct that most client/server implementations use dynamic
SQL interfaces which are weak from a security perspective.  But that's
not a fixed attribute of c/s interfaces.  IBM's DRDA, for example,
supports the same encapsulation you described for non-c/s: an
application's SQL statements can be bound to the server and become the
entity to which (execution) access is granted.  It is, however, harder
to maintain a reliable binding between a remote client application
program and it's server appendage.

Stored procedures and other forms of RPC access do provide a similar
benefit although the problem of client program integrity remains.

A more profound problem in client/server security is authentication
of the client, particularly in a wide network.  SNA provides security
mechanisms at both the connection and conversation levels but quality
of SNA implementation varies from system to system.  "Real" security
over a network means using a 3-party system like Kerberose.

/b
----------
Bill Manry
Oracle Corp.  /  Mainframe & Integration Technologies  /  BManry@us.oracle.com
#include <disclaimer.usual>