And update privileges table with grant option
914 Part V ✦ Managing Oracle Security
TABLE | VIEW | SEQUENCE |
|
|
---|---|---|---|---|
|
X | X | X | |
X | X | |||
X | X | |||
X | X | |||
X | X | |||
X | ||||
|
X | |||
|
||||
X |
GRANT ALL [PRIVILEGES] | object_priv [(column, column, ...)] [, object_priv [(column, column, ...(] , ...]
ON [schema_name.]object_name
TO user | role | PUBLIC
[, user | role | PUBLIC, ...]
[WITH GRANT OPTION]A number of elements of the syntax need further scrutiny:
For example, if the owner of a table issues the command GRANT ALL, the privileges that will be granted are those that are available for a table, namely SELECT, INSERT, UPDATE, DELETE, ALTER, INDEX, and REFERENCES. However, if the GRANT ALL syntax is issued by someone that has been granted the SELECT, INSERT, and UPDATE privileges on a table WITH GRANT OPTION, then the only privileges that will be granted are those which the grantor (that is, the user doing the granting) has, namely SELECT, INSERT, and UPDATE.
✦ It is possible to grant privileges for users to perform INSERT, UPDATE, or REFERENCES operations on individual columns of a table or view by including a column list in the GRANT command. While this may seem like a good idea in that it gives you precise control over the columns that users have access to, it can become a nightmare to maintain and should be avoided. If you need to limit the columns a user should have privileges to, create a view with only those columns and then grant the user the appropriate privileges on the view.
SQL>
The best way to succeed in granting object privileges to users is to be connected to the instance as the owner of the object and then grant the privileges as required, as in this example: