Securing Database 9i, User rights

I have mid-size database that have multiple schemas. The schema usually accessed by applications. However, there is 5 users who access the database locally to check some infomations.  In the past they used to logon as system which cuase some problems! I want to create accounts for them and give them read-only for all user create schema (no system access). and I would like to track which user did what.
 

grant select any table ....... privilage to the users this solves the first part.
As you're on 9i , you can use the FGA (Fine Grained Auditing) feature to track the select queries given by the users.
 

Grant select, resource will gives them read only? will that enable them to view the data via EM and change or not? I think once they logged in the EM they will be able to change data?
 

Select is a read only privilage on a table. Why don't you try it out so that your doubts are cleared.
 

I did test it. the user who have select any table, will not be able to login to EM, becuase EM have have many data dictionary parameters and instance, storage and so on. but after

grant create session
grant select any dictionry
grant select any table

Then it works fine. So I will create new rule "test" and give it the above rights then assign it to the users.

Have a Oracle Question
Do you have an Oracle Question?

Oracle Books
Oracle Certification, Database Administration, SQL, Application, Programming Reference Books

Oracle Application
Oracle Application Hints and Tips

Oracle Home
Oracle Database, SQL, Application, Programming Tips

All the site contents are Copyright © www.erpgreat.com and the content authors. All rights reserved.
All product names are trademarks of their respective companies.
The site www.erpgreat.com is not affiliated with or endorsed by any company listed at this site.
Every effort is made to ensure the content integrity.  Information used on this site is at your own risk.
 The content on this site may not be reproduced or redistributed without the express written permission of
www.erpgreat.com or the content authors.