Archives of the TeradataForum

Message Posted: Thu, 10 Mar 2005 @ 19:05:13 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Profiles have two major security flaws. Any userid authorized to manage profiles can change *any* profile on the system, a real headache in an environment shared by multiple applications. But the real killer is the way that profiles can override the parameters in dbc.syssecdefaults. NCR could fix it by requiring that profiles can never be less restrictive than dbc.syssecdefaults, but I don't know if they have any plans in that direction.

Roles look more promising, though we had some confusion initially with the problems that profiles were having. We used to create user groups by creating a container database with the permissions needed for the group, and then creating the userids for that group in the container database. The userids would inherit their rights from the container and all was well. We can implement this scheme using roles to replace the container databases, but it doesn't buy us much to improve the rights administration.

We also want to have multiple roles for users who cross application boundaries and that's fairly easy. But what we really want is to define layered roles for increasing access authority based on job function. I'm not sure we'll get there, but we're trying. Example:

The old way:

     End user: SELECT on MYDATABASE
     Advanced user:  SELECT, INSERT, DELETE, UPDATE on MYDATABASE
     Developer: SELECT, INSERT, DELETE, UPDATE, TABLE, VIEW on MYDATABASE
     DBA: SELECT, INSERT, DELETE, UPDATE, TABLE, VIEW, DATABASE on MYDATABASE

The new way:

     End user: SELECT on MYDATABASE
     Advanced user: INSERT, DELETE, UPDATE on MYDATABASE
     Developer: TABLE, VIEW on MYDATABASE
     DBA: DATABASE on MYDATABASE

In the old way, roles with increased authority are supersets of lesser roles. In the new way, each layer has a specific set of rights granted to that job function and user has to have multiple roles in operation simultaneously to get the correct set of rights. I'm still not sure if this is possible, but it would be the easiest way to manage things.

/dave hough

	<Prev	Next>		<<First	<Prev	Next>	Last>>