I want to know which privilege is required to access the table ALL_ARGUMENTS in Oracle? There is any specific one?
Example:
SELECT * FROM ALL_ARGUMENTS
Searched on web but found nothing.
The ALL_ARGUMENTS table is returned when we execute this:
SELECT * FROM sys.dba_tab_privs WHERE grantee='PUBLIC' and table_name like 'ALL_ARGUMENTS'
We see a value of PUBLIC as the grantee. That means, PUBLIC has SELECT privilege.
Reference: https://docs.oracle.com/database/121/TTSYS/systemtables.htm#TTSYS348
There may be other tables in SYS, for which this is not true: Then, ADMIN or SELECT ANY TABLE privileges are needed.
Typically, anyone can see ALL_ARGUMENTS. For that matter, anyone can see any ALL_ data dictionary view.
It will show you YOUR arguments, and any argument for an object you are also able to view based on your privilege level.
This security check is why querying DBA_ views is always (generally) faster than querying ALL_ views - because it just shows EVERY SINGLE ARGUMENT regardless of object privileges.
Not every view has an ALL_ and a DBA_ version.
From the DOCS
Related
I am new to schema and not sure how the table is being populated (How the data is being inserted into the table ). How can we find out ?
This should work.
select *
from dba_source
where upper(text) like '%TABLE_NAME%'
But as I do not have DBA rights , can not execute this command. What is the other way to find this out ?
To see dependencies between objects you have access to you can query the all_dependencies data dictionary view. In this case:
select * from all_dependencies where referenced_name = 'YOUR_TABLE_NAME';
If the objects are in your own schema when you can use the user_dependencies view. If you want to see objects you don't have privileges against then you can use dba_dependencies, but it sounds like you are unlikely to have the privileges required to query that view, since you can't see dba_source.
Of course, that will only identify references within your stored PL/SQL code; it won't tell you about any external application code that is performing inserts directly against the database (as opposed to via CRUD procedures) or manual inserts.
And it will only tell you which objects have dependencies, you'll still need to dig through the object source code, either by querying all_source (or user_source if you're the owner) for the relevant type and name. I would avoid the possibility of false-positives from, say, comments that happen to mention the table name in code which doesn't access it. You could also do that outside the database - hopefully your code is under source control (right!?).
If you know the query you need to run but do not have the necessary privileges then perhaps you can write the query using USER_ or ALL_ views to validate the syntax then change the view to DBA_ and ask the DBA to run the query for you.
I would simply like to allow a colleague to view and edit the Database I've created.
I've tried:
GRANT ALL on FISHTABLE to CDEMARES;
and it returned Grant succeeded but nothing changed for him and he still wasn't able to view my table.
I also tried
GRANT SELECT smahala.fishtable to cdemares#sole.nefsc.noaa.gov;
but that failed with SQL Error: ORA_00990: missing or invalid privilege.
Is my issue that I don't have the administrative authority to allow someone else to view my Oracle table? Any advice is appreciated, thanks.
Your colleague needs to prefix your table with your schema name, otherwise Oracle doesn't know where to look for it, e.g.:
select * from smahala.fishtable
If they don't do that, and simply try to use:
select * from fishtable
then Oracle will look for the table in their own schema, and then look for a view, or a private synonym, or a public synonym. Your colleague could create a synonym if they'll be accessing this table a lot (and they don't have their own table with the same name). It's also possible to change their session's current schema, but that will make it harder to see their own objects.
You can read more about object naming and how to refer to objects in the documentation.
SQL Developer allows you to browse objects in other schemas. If your colleague was connected when you granted the permissions, they can refresh the object list, or disconnect and reconnect. Either way they should then be abke to see your table under your schema.
(Your second grant statement is missing an on, and you can't grant permissions across a database link, if that's what you're trying to do.)
Referring to here and here
Would a user need both SELECT /INSERT/DELETE/UPDATE, etc. privileges on the view AND on the underlying table to be able to perform these actions ? Or privileges on EITHER table/view is enough ?
In other words, consider a user A owning the table T and the view V (constructed from T). Can a user B with SELECT right on V execute a SELECT if he does not SELECT right on T, and vice-versa ? If he could, wouldn't that mean the View privilege "overrides" the table privilege, as A does not give him right over T ?
Update
In a related question, how about synonym ? From what I understand in a book, users need both SELECT privileges on the synonym and the underlying table. This will be different from views.
On the other hand, Oracle seems to indicate that synonyms behave similar to views.
A user can be granted the SELECT privilege on a synonym or a view
without being explicitly granted the SELECT privilege on the
originating table
Update 2
Following everyone's answer that we only need the privileges on view to select the table (at least what the view sees from the table) and no privilege on table is needed, let's consider this scenario :
Table T belongs to A
A GRANT SELECT ON T to B (without GRANT OPTION)
B CREATE VIEW V AS SELECT * FROM A.T
B GRANT SELECT ON V TO C
C performing SELECT * FROM B.V
According to what you have said, C will be able to select from V, therefore equivalent to selecting from T. Is it that cheating ? B is effectively letting C seeing A.T although C does not have the right on T and B does not have GRANT OPTION. Is there a security hole somewhere ?
One of the fundamental uses of views is to protect privacy. A base table may have confidential information that some users don't need to see (for example, in an employee table, you may have salary). Some users need access to query (select), or to update, only certain fields from the base table, without having access to the full information. For example: select phone number, or update address (but no access to see salary or bonus). Then one would create a view and give those users "select" and "update" privileges on the view only, and not on the base table. (The select still goes against the base table, but the COLUMNS will be limited to those included in the view... updates can/will be made to the base table, but again, only for values in the columns included in the view.) The view can limit not only the columns, but also the rows - for example, with a WHERE clause in the view, you may exclude the CEO from the view completely.
So, one of the main uses of views is based exactly on that: some users may have privileges on the view, but not on the base table.
Yes. Usually the view runs as the view owner, and the user runs with permission on the view. So user b only needs access to the view.
However when looking at this sort of question, you may want to look into row level security as well. This works by granting access to a portion of the table to a given user or group (i.e. effectively enforcing where clauses at the end of queries). Depending on your use case, it may be simpler or more complex to manage.
I'm working on a Groovy/Grails project that will display the roles that a user is currently assigned in an Oracle database. Is it possible to query this information from the Oracle server via Groovy/Grails? If it is, any pointers on how to do this are much appreciated.
There are a lot of oracle metadata views available. First of all there is a prefix DBA_, ALL_, USER_ describes how much data you will see (depending on your permissions). I will list only DBA_ prefix, you could replace it with more restrictive prefix.
You will be interested in views:
DBA_ROLES
DBA_ROLE_PRIVS
ROLE_TAB_PRIVS
DBA_TAB_PRIVS
DBA_USERS
SESSION_PRIVS
SESSION_ROLES
TABLE_PRIVILEGES
A third party product we have at my company uses Oracle as a backend. I'm attempting to log into the Oracle database and look at the schema and data. I've logged in as sys/sysdba, created a user with a default tablespace of that created by the application, and granted the user all necessary permissions to query the structures. I've also set O7_DICTIONARY_ACCESSIBILITY to true to allow querying of the data dictionary objects.
After logging in as the user and querying User_Tables nothing is returned. But when I query DBA_Tables the tables I'd expect to find are returned. I'm new to Oracle so I'm not quite certain how a non-system table can be in the tablespace, but not a user_table.
More importantly, how do you query the data in these tables? Whenever I attempt a simple "Select *" from the tables I get a "table or view does not exist" error.
Thanks in advance.
The default tablespace you set for a user controls what tablespace objects owned by that user are created in. It has nothing to do with what objects they can query.
USER_TABLES returns information about the tables that a particular user owns. It does not sound like your user owns any tables, so you would expect that to be empty.
ALL_TABLES returns information about the tables that a particular user has access to. If you granted the appropriate privileges, your user should see the tables in this data dictionary view.
DBA_TABLES returns information about every table in the database even if you don't necessarily have access to the underlying table.
If you are trying to query data from one of the tables, are you specifying the schema name (the OWNER column in ALL_TABLES)? If you do not own an object, you generally need to use fully qualified names to reference it, i.e.
SELECT *
FROM schema_owner.table_name
You can avoid using fully qualified names if
You create a synonym (public or private) for the object
You change the CURRENT_SCHEMA for the session. This changes the default schema that a name is resolved under. It does not affect permissions and privileges. You can change the current schema with the command
ALTER SESSION SET current_schema = new_schema_name
You would have to do this for each session the user creates-- potentially in a login trigger.