User VS Schema

Question

Hi,
I have a database where there is only one schema, say SCHEMA1, to which the application connects.
Now, I am to create three more users, user1, user2, and user3, who must be able to connect to SCHEMA1.
User1:
Must have read, write, drop and all other relevant privileges on SCHEMA1. All priveleges that the owner of SCHEMA1 has.
User2 and User3:
Must have only read access to all objects in the schema.
Users 1, 2, and 3 must be audited.
Is there a way other than granting privileges on each of the object in SCHEMA1 recursively? Something like granting read/write privileges on the schema as a whole?
Also, any such statement as CREATE TABLE/CREATE VIEW/CREATE INDEX/... should actually create the object in SCHEMA1 and not in the schema associated with USER1.
Thanks,
Aswin.

Answer 1

ice_cold_aswin wrote:
Hi,
I have a database where there is only one schema, say SCHEMA1, to which the application connects.
Now, I am to create three more users, user1, user2, and user3, who must be able to connect to SCHEMA1.No, they don't "connect to" schema1. They connect as themselves and are granted minimal privileges to selected objects in schema1.
>
User1:
Must have read, write, drop and all other relevant privileges on SCHEMA1. All priveleges that the owner of SCHEMA1 has.If you give them create/alter/drop schema1 objects, you are on the fast-track to DBA hell.
>
User2 and User3:
Must have only read access to all objects in the schema.
So create a role, grant only SELECT to that role (GRANT SELECT ON SCHEMA1.TABLE1 TO MYROLE) and grant that role to user2 and user3
Users 1, 2, and 3 must be audited.
So turn on the necessary auditing. That is a totally separate function.
Is there a way other than granting privileges on each of the object in SCHEMA1 recursively? Something like granting read/write privileges on the schema as a whole?
What would be recursive? Grant the necessary privileges to a role. Grant the role to the necessary users.
Also, any such statement as CREATE TABLE/CREATE VIEW/CREATE INDEX/... should actually create the object in SCHEMA1 and not in the schema associated with USER1.
Again, user1 absolutely should not be allowed to execute DDL against another schema. In fact, I'd question if USER1 should be allowed to execute DDL at all. If you think it is necessary for your application, I'd question the basic assumptions of the application design.
The objects (tables, etc) needed by the application should belong to a schema created for that sole purpose. Since a schema is the collection of objects belonging to a user (and thus the common confusion between the concept of "user" vs. "schema"), the user created to own the application schema is usually locked. No reason for anyone to actually connect to the database with those credentials. User accounts typically don't actually own any objects. They are granted CREATE SESSION and whatever other minimal privs needed to access the objects owned by the application schema.
Thanks,
Aswin.