I have two tables. a) student b) restricted_student.
two users a) admin b) user
one synonyms stu for both the users. in admin it refer to student but for user it refer to restricted_student.
I want to create a materialized view MV .
The code of materialized view look like
CREATE MATERIALIZED VIEW SELECT TABLE_NAME,COLUMN_NAME FROM USER_TAB_COLUMNS;
such that if i am connected to admin then it should refer to student and for user it should refer to restricted_student by passing the only synonyms name stu.
something like
SELECT TABLE_NAME,COLUMN_NAME FROM USER_TAB_COLUMNS E='st';
the result i wanted when i connected to user it should give the restricted_student table columns. whereas whenever i connected to admin it should give the student table columns.
I created all the above objects.but materialized view is not giving the expected result as i want.
You can use a normal view where you can union these 2 tables and filter by the user logged in.
Also check Oracle RLS (row level security), https://docs.oracle.com/cd/B28359_01/network.111/b28529/intro.htm
Irrespective of the application and user, you can control how the where clause should be. That way you have a much higher control over the records that is queries.
For example,
Admin user
select * from stu;
Normal user
select * from stu;
Would have completely different results, based on the predicate you set for RLS.
Related
I have a table configured with an OLS policy (levels, compartments, groups) - a user with a specific OLS user label can only access some rows in the table according to their OLS data label. Right now, I'm using strings to connect to the Oracle Database then make a query from that table (like "select * from mytable"). May I ask is it possible to use Entity Context for that? Like one data context but multiple user Oracle account (schemas) with different user labels query from that single Entity context so that I don't have to use strings?
Label security (OLS) affects the rows shown to a user - not colums etc.
i.e. the data model is for any user allowed to select the tables the same - so if you got User1 granted to select table T1 but OLS restricted access for User1 to data connected to asian location, User1 will see only asian data but not rows for european locations - If User2 is a "superuser" - i.e. allowed to fetch rows from any location, User2 will see any rows.
The simpliest way to prove this is to do
desc T1
Both users will see same table description - and thats what EF / LINQ relates on. So - as User with OLS and granted select table you got 0, subset or all rows - but Everytime table description
I need to get a list of all users and their tables and details.
For Example : https://www.google.com/search?q=oracle+user&source=lnms&tbm=isch&sa=X&ved=0ahUKEwi-td2pjcPMAhXEFh4KHdMAAVcQ_AUIBygB&biw=1175&bih=621#tbm=isch&q=oracle+user++sql+developer&imgrc=Qvmfp57HchgwgM%3A
In the above screen towards left there is red color symbol (User) , SO i need the username, associated tables(under that user) and atrributes in that table. Is this possible. for all users.
Thanks
Addy
ALL USERS, ALL TABLES, 'and details'
So do you really want ALL the users? Because many users are system users - users that own objects that the database itself uses, SYS being the biggest example. You could have dozens of these accounts. I'm guessing you don't want them.
All tables, tables in the recycle bin, tables there for materialized views, do you want those too?
And 'details'. Do you want their created date, their columns, their storage parameters? The more you want, the bigger and uglier your query is going to get.
All that being said, you pointed to a screenshot of Oracle SQL Developer. It contains a data modeling feature. Use it. Reverse engineer the users you really want into a data model. And then use the data dictionary reports it offers to give you the info you want.
You have to figure out what you REALLY want first though.
I talk about how to do the RE in the data modeler here.
You can start from this:
select *
from dba_tables t
inner join dba_tab_columns
using(owner, table_name)
This will give all the tables and columns, with some informations about tablespace, the type of the columns, and so on
This shows all the users and all their tables except for SYS and SYSTEM
SELECT owner, table_name
FROM All_All_Tables
WHERE owner NOT IN ('SYS','SYSTEM')
ORDER BY 1,2
Runs on Oracle 10, 11
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 have an Oracle Database with a schema A, which has select privilege on DBA_* views.
I also have an schema B that doesn't have these privilege, but it has a lot of materialized views.
In schema A, there are three refresh groups, each one having some materialized views from schema B.
I'd like to check whether there are snapshots out of the refresh groups, but I'd like to do this check connected as B.
I'm using the following query to perform this check in schema A:
SELECT OWNER, NAME FROM DBA_SNAPSHOTS WHERE OWNER = 'B'
MINUS
SELECT OWNER, NAME FROM DBA_REFRESH_CHILDREN WHERE RNAME IN ('REFRESH_G1','REFRESH_G2','REFRESH_G3');
The problems:
B doesn't have privileges on DBA_* views (and It can't have)
If I change DBA_* views for ALL_* views, B can't see the refresh groups (and I can not grant alter any materialized view to B)
So:
Is there another way to perform this check in B?
Or is there another way to make B see the refresh groups?
Or is there a way to "freeze" the result of the query using ALL_* views, such as B will see the result of the query as A?
Thanks!
On A
CREATE OR REPLACE VIEW V_REFRESH_SNAPSHOT AS
SELECT OWNER, NAME FROM DBA_SNAPSHOTS WHERE OWNER = 'B'
MINUS
SELECT OWNER, NAME FROM DBA_REFRESH_CHILDREN WHERE RNAME IN ('REFRESH_G1','REFRESH_G2','REFRESH_G3');
GRANT SELECT ON A.V_REFRESH_SNAPSHOT TO B;
From B
SELECT * FROM A.V_REFRESH_SNAPSHOT;
I have a view that is built on multiple tables from different users schema. By virtue of the currently logged in user, he is able to see the table from different schema. When the view is created the table name becomes ambiguous as the user have access to the same tables from the different schema.
Is there any way to specify to use the table from current user schema while creating the view?
Can we do it for one of the tables from the view definition while other tables can be selected from any schema?
"When the view is created the table
name becomes ambiguous as the user
have access to the same tables from
the different schema"
It isn't ambiguous to Oracle.
The view exists in a schema, SCHEMA_1. If that view refers to an object TABLE_A, Oracle will first look for an object TABLE_A in SCHEMA_1. If it finds a table, it will use that. If it finds a SYNONYM it will use whatever the synonym points to. If there is nothing in SCHEMA_1, it will look for a PUBLIC SYNONYM for TABLE_A and use whatever that points to.
SYNONYMS can point to other synonyms, views or tables.
You can query USER_DEPENDENCIES to see what objects the view is actually based on.
You cannot have a view in SCHEMA_1 that uses TABLE_A in SCHEMA_2 if queried from SCHEMA_2 but uses a different TABLE_A in SCHEMA_3 if queried from SCHEMA_3.
You should be able to access schema (with correct permissions) by prefixing the schema name.
schemaname.tablename
Hope I understood your question correctly.