I have administrative problem on my database.
I need to give permission to other schema to my View. My View have data from one table and view. This Second view is using private database link.
How can i grant select on that View, to other schema and in the same time grant view that is using database link?
While trying making simple
grant select on myView to otherSchema;
i have error ORA-02021: DDL operations are not allowed on a remote database
DDL operations of any kind, such as grants, are not allowed to be executed through a database link. You need to connect to the remote database where the source objects are located, and grant select on them to the user/schema who connects by dblink. As you don't provide any code, consider the option that you might need to use grant select on xxxx with grant option.
Related
I'm trying to retrieve the CREATE table statement for multiple tables from oracle SQL Developer so I can run it in SQL Management to create new tables.
However, when highlighting multiple tables and right clicking > Quick DLL> Save to File, my file looks like this:
GRANT INSERT ON "OPSR"."BOOTH" TO "OPSWEB";
GRANT UPDATE ON "OPSR"."BOOTH" TO "OPSWEB";
GRANT SELECT ON "OPSR"."BOOTH" TO "OPSWEB";
GRANT DELETE ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
GRANT INSERT ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
GRANT SELECT ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
GRANT UPDATE ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
Why is there no CREATE table statements in here?
I'm connected as Opsweb and the only tables I can see are under the OPSR user.
You can't see the create DDL for other user's objects. SQL Developer is using dbms_metadata in the background, and from the documentation:
The object views of the Oracle metadata model implement security as follows:
Nonprivileged users can see the metadata of only their own objects.
Nonprivileged users can also retrieve public synonyms, system privileges granted to them, and object privileges granted to them or by them to others. This also includes privileges granted to PUBLIC.
If callers request objects they are not privileged to retrieve, no exception is raised; the object is simply not retrieved.
If nonprivileged users are granted some form of access to an object in someone else's schema, they will be able to retrieve the grant specification through the Metadata API, but not the object's actual metadata.
and so on. As the last bullet above says, you cen get the grants - which is what you are seeing now - but not the actual metadata.
If your user was granted the select_catalog_role you would be able to get the DDL for OPSR's objects, but you'd have to ask your DBA for that and it would probably be easier to connect as that user, or ask someone else who can to do that to perform the extract for you.
I have created a view in Database A that looks at tables in Database B that the users in Database A do not have access to (HR Data).
Is there a way I can grant anybody calling the view in Database A permissions to see the results, without giving access to the underlying tables?
Both databases are on the same instance, SQL Server 2019
You can just
GRANT SELECT ON OBJECT::[schema].[theView] TO User1,User2
in your Database A? This way you'd just give SELECT permissions to the view itself, and not the tables.
If you have a lot of cases like this, you can also consider creating a special schema for this and do:
GRANT select ON Schema :: [DBO] TO User1
instead.
I need to restrict SELECT access to a table in Firebird 3.0, so that not all columns can be read by the user.
This FAQ entry suggests to create a view with the restricted columns and then grant SELECT only on this view. However if I do that and connect with the restricted user with FlameRobin and try to select from the view, the error says I don't have SELECT rights to select from the underlying table. But If I grant access to that table, all columns can be read...
How can I grant SELECT access only to the restricting view and not to the whole underlying table?
Since you do not want your user to have grants on the table, then it is the VIEW which should have, (or a selectable Stored Procedure, when user permissions are regulated with SPs). The user "invokes" the VIEW (or an SP) and then the VIEW invokes the table.
GRANT SELECT ON mytable TO VIEW myview
You have to grant table read rights to the view, not to the users. Read chapter 11.2.2. Statements for Granting Privileges in Firebird documentation at https://firebirdsql.org/file/documentation/html/en/refdocs/fblangref25/firebird-25-language-reference.html#fblangref25-security-auth-manage-users
To be able to select from a view, you need to grant the SELECT privilege on the view to the user, however, to be able to select from the view, either the user or the view must have the SELECT privilege on the table(s) used in that view.
In this case, you don't want the user to have access to the underlying table, so you need to grant the necessary privileges to the view:
GRANT SELECT ON TABLE <sourcetable> TO VIEW <yourview>
See also Statements for Granting Privileges in the Firebird 2.5 Language Reference.
When I try to create a view by using different tables(from different users), getting grant option does not exist for (dependent table) even though Privileges(WITH GRANT OPTION) exists on dependent tables to respective user but when I execute same dependent Select query of creating view it's running successfully.
create or replace view ein.eswar
as
select * from ron.anil t ,msd.ram v where t.id=v.id;
grant option does not exist for ron.anil;
After dropping view and recreating it successfully without any issues. Please explain.
You need to have privilege SELECT WITH GRANT option;
GRANT SELECT ON ron.anil TO EIN WITH GRANT OPTION.
When you are creating view on different schema then table_owner, privilege with grant option are necessary.
I’m pulling data from mysql ec2 instances, to s3 buckets, then creating views in redshift. I want to create database users who can only query and see certain views created specifically for them in Redshift. I have example code below that I use to create the user, view, and grant access. The issue I have is that I also have to grant access to the underlying schema the view is created from, which means the user can see and query tables in that schema. Also the user can see other schemas in the database, even ones they can’t query. Is there a way to only grant users to specific views, and make it so they can’t see other schemas they don’t have access to?
Code:
--create schema
create schema tst_user_schema;
--create view in schema
create view tst_user_schema.inventory_report_customer as (
select * from user341.inventory_report_customer
)
with no schema binding;
--creating user
CREATE USER tstuser PASSWORD 'tstPassword';
--grant access
GRANT USAGE ON SCHEMA tst_user_schema TO tstuser;
--grant read access to all tables in schema
GRANT SELECT ON ALL TABLES IN SCHEMA tst_user_schema TO tstuser;
--grant access
GRANT USAGE ON SCHEMA user341 TO tstuser;
--grant read access to all tables in schema
GRANT SELECT ON ALL TABLES IN SCHEMA user341 TO tstuser;
--grant access
GRANT USAGE ON SCHEMA tst_user_schema TO tstuser;
--grant read access to all tables in schema
GRANT SELECT ON ALL TABLES IN SCHEMA tst_user_schema TO tstuser;
to recap:
schema user341 - contains source tables, user should not be able to select from tables in this schema. You also want to hide it form the user
tst_user_schema - contains views user is supposed to be able to select from.
Looking at your GRANT statements, you're granting user unnecessarily SELECT permission on ALL TABLES IN SCHEMA user341. For views to work you only need to GRANT USAGE on that schema.
So REVOKE those permissions, and user should not be able to select.
REVOKE SELECT ON ALL TABLES IN SCHEMA user341 FROM tstuser;
Tip: to easily test permissions, you can start a session as tstuser using SET SESSION AUTHORIZATION directive and then test which statements are allowed and which not.
SET SESSION AUTHORIZATION tstuser
Regarding schema visibility - unfortunately there's no way to hide or forbid user from seening all tables and columns in all schemas. One can only restrict access to data.