Re: Security options at differe

->Yes, certainly. But it is not possible right now to build-in all the rules ->you need to provide the security needed. As for DB2 you can (as far as you ->use Embedded Static SQL) enable the user to access tables without having ->the appropriate privileges himself. So you can grant him for SELECT on ->tables he has to evaluate individually with a querytool although he is able ->to update this table from within his application. > I don't understand - what stops me writing my own "Embedded Static > SQL" application to access the database and I can get around the > security that way. That is the problem mentioned here. How to > distingush between different applications running as the same user. I believe that what the original posting was getting at involves the DB2 bind operation. After SQL precompilation, you end up with one file that you pass to the compiler and linkeditor just like any other program. You also end up with a file which is run through another process which builds the access plan and stores it in the database SYSPLAN table (or SYSPACKAGE, if you're using packages). At the time of binding, an authorization ID is assigned to the plan. When the program runs, whoever runs it has the authority allowed by the auth ID. If the DBA performs the bind, and sets the auth ID appropriately, anyone who has execute authority on that plan (or package) can access tables in ways in which they normally could not. This is roughly analogous to using stored procedures as a security feature in Informix.