Snyds wrote:There is one exception. Privileges granted directly to PUBLIC are as good as privileges granted directly to an individual user. This sounds like a development (or student) database, so letting anyone in the database see what's in CM_MASTER.TABLE_NAME might be okay. Again, this lets everybody in the database see that table; not just the users who have the sr_project_role.
... While researching this issue I found the statement below:
“The owner of the procedure or package must have been explicitly granted the necessary object privileges for all objects referenced within the body of the code; the owner cannot have obtained required privileges through roles.”
Is this true? My testing seems to confirm this. ...
Snyds wrote:In most databases, you'll end up with a relatively small number of users that need to own PL/SQL objects and that need direct grants and boatloads of users that simply need permission to access objects owned by other users. Roles exist to simplify the task of managing the privileges of that vast majority of database user accounts and to provide additional security mechanisms. For example, roles can be made default or non-default or can require an additional password so your applications can easily enable or disable particular roles based on whatever logic you want or you can make it more difficult for users that fire up SQL*Plus connecting to the database to exercise their most dangerous privileges by requiring an extra step of enabling an additional role (with or without an additional password being required).
My question was almost rhetorical in that if roles do not provide the privileges needed why use them.