> I'm not so sure I would call this a security hole. If I could figure > it out, it might just be a security feature in that one could shut > down access via UniObjects for users who have no business accessing > the system that way.
I go back to my original argument, perhaps explained more clearly (I hope) this time.... Imagine you run a bank. Your employees log in each day from their desktop PC using a UniObjects based application and shuffle money about between accounts. The application must have write access to the database files and controls who can do what via its own internal security checks. A clever employee now writes a simple VB program that uses UniObjects and puts it on his PC. This program connects to the server using his username/password but, instead of calling the usual application modules, uses UniObjects to open the files and transfer funds into his own account totally outside the security of the application. Using any of the operating system or database security mechanisms shuts out the business application as well as the rogue user. The only way that I can see to close this hole is for UniObjects to have an option to restrict which operations the client end can request. At the highest level, this should restrict the client so that all he can do is call existing catalogued programs that are compiled with some special compiler mode directive. Come on... Someone convince me I'm wrong! Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
