davidm@uunet.UU.NET (David S. Masterson) (03/17/90)
I'm looking to find out the typical methods that layered product developers use for enforcing security in an RDBMS. The typical method for security is to develop views of the database and allow users to only work with the particular views that cover the data that they are allowed to see. However, to me it would seem that a layered product developer (like an accounting system developer) could not work with views as views are typically developed at the installation site and, so, the program cannot be developed to understand them. Because of views, a database administrator could protect the database such that the layered product would not work and the layered product wouldn't be able to understand why. Does anyone have a model for developing the security mechanism of a layered product as an extension to the security view mechanism of relational database systems? Remember, most (all?) relational database systems allow updates of views if the view is over one base table. Also, a view developed at a site could only be accessed by dynamic SQL (and thus, incur its overhead). Must the layered product run as a psuedo-user (like root) in order to gain access to the base tables (and thus potentially unlimited power) or is there a mechanism that allows them to coexist better? -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"