> The kinds of requirements are all too common from managers and > security > people. > it generally comes down to a generic 'best practice' or some other > nonsensical > 2 word answers So it all comes down to the principle of least privilege and it's a principle for a very good reason. The more a user can do or the more a user can access the easier it becomes to compromise the system. In this case, giving read access to a list of users or database parameters might sound benign to you or I but who knows what having access to that info could lead to. Just ask Matt Honan about how dangerous a little information can be (http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/all/) Or for a real world example on how an attacker can bootstrap from user to DBA on Oracle have a read of this "Indirect Privilege Escalation" (http://www.databasesecurity.com/dbsec/ohh-indirect-privilege-escalation.pdf) This basically takes a normal user to DBA via exploiting a flaw in a MDSYS owned trigger to create a trigger in the SYSTEM schema and from there to grant the DBA role. Whilst the example in this document injects a user-defined function, I extend the attack to show how a user with only CREATE SESSION privileges can exploit the same flaw to get DBA - http://www.databasesecurity.com/dbsec/cursor-injection.pdf - by injecting a pre-defined cursor and DBMS_SQL.EXECUTE. We don't know how access to information may make us vulnerable further on down the line but by adhering to this principle, in every case - even if it's not evident why we should do so - it helps keep us protected. Bottom line is the principle of least privilege is a sound principle and it helps keep data secure. It might mean a bit more work but it helps protect your vital assets and your customers. Just my $0.02 as a security guy :) Cheers, David Litchfield -- //www.freelists.org/webpage/oracle-l