Re: Security for group of users ???

In article <35bdd1f5.103872360_at_news.muc>,   Wolfgang.Rothmayer_at_bmw.de wrote:
> Hi Alan,
>
> as some ORACLE experts told me, one way to hide some users from the DB
> is to add entries to the PRODUCT_USER_PROFILE table.
> There you can specify which ORACLE products (i.e SQL*PLUS) may not be
> accessible to some users.
>
> Thank you for jumpinī in :-)
>
> Wolfgang.
>

[snip]

Here's some more on that

1. Each application should have distinct roles:

     One role should contain all privileges necessary to use the application successfully. Depending on the situation, there

     might be several roles that contain more or fewer privileges to provide tighter or less restrictive security while executing

     the application. Each application role should be protected by a password (or by operating system authentication) to

     prevent unauthorized use.

  Another role should contain only non-destructive privileges associated with the application (that is, SELECT privileges for specific tables or views associated with the application). The read-only role allows the application user to generate custom reports using ad hoc tools such as SQL*Plus, SQL*ReportWriter, SQL*Graph, etc. However, this role does not allow the application user to modify table data outside the application itself. A role designed for an ad hoc query tool may or may not be protected by a password (or operating system authentication).

     2. At startup, each application should use the SET ROLE command to enable one of the application roles associated

     with that application. If a password is used to authorize the role, the password must be included in the SET ROLE

     statement within the application (encrypted by the application, if possible); if the role is authorized by the operating

     system, the system administrator must have set up user accounts and applications so that application users get the

     appropriate operating system privileges when using the application.

     3. At termination, each application should disable the previously enabled application role.

  4. Application users should be granted application roles, as required. The administrator can prohibit a user from using application data with ad hoc tools by not granting the non-destructive role to the user.

Using this configuration, each application enables the proper role when the application is started, and disables the role when the application terminates. If an application user decides to use an ad hoc tool, the user can only enable the non-destructive role intended for that tool.

Additionally, you can

     Specify the roles to enable when a user starts SQL*Plus, using the PRODUCT_USER_PROFILE table. This

     functionality is similar to that of a precompiler or OCI application that issues a SET ROLE statement to enable specific

     roles upon application startup.

     Disable the use of the SET ROLE command for SQL*Plus users with the PRODUCT_USER_PROFILE table. This

     allows a SQL*Plus user only the privileges associated with the roles enabled when the user started SQL*Plus.

Other ad hoc query and reporting tools, such as SQL*ReportWriter, SQL*Graph, etc., can also make use of the PRODUCT_USER_PROFILE table to restrict the roles and commands that each user can use while running that product. For more information about these features, see the appropriate tool manual.

Regards

--
Oliver Willandsen
European Commission
http://europa.eu.int
All remarks are my own and do not necessarily reflect official European Commission policy

-----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum Received on Tue Jul 28 1998 - 12:01:31 CDT