I have some public functions in vertica. I want to create a read only user in vertica who can access only the data tables in the defined schema and not from v_catalog(Information_schema) to list all the table names. Is it possible in vertica to create a user who can be restricted to use any system commands but can access the public functions and UDFS and execute only select command in the defined schema.
If you create a user, the only role the user is granted is PUBLIC.
All that is granted to PUBLIC , but nothing more, will be granted to the new user.
Once the new user is logged in, if no tables exist that are granted to PUBLIC, a SELECT * FROM v_catalog.tables; will return an empty table.
If I were you , I would create a user, as dbadmin:
CREATE USER marvin IDENTIFIED BY 'heart_of_gold';
Then, I'd log in as that user:
vsql -U marvin -w heart_of_gold -h 00.000.000.00 -d dbname
And then, try all sorts of queries to see what I'm allowed to do; then log back in as dbadmin, grant some things to marvin and see what happens.
And check the Vertica documentation around the GRANT command to find out what can be granted and revoked. I do it exactly like that until I feel confident about what I'm trying to achieve..
Good luck and happy playing
Related
how can I run worksheet or just import some function into OtherUsers folder.
OtherUsers/something/functions . I have no idea how can I do this.
Propably it's very simple.
It depends on the privileges you have on the database. Typically a user account will have abilities to create objects in their own schema, but not others. You can query SESSION_PRIVS to see what privileges you have in your session. If you see (for example) CREATE TABLE, you can create tables in your account. If you see CREATE ANY TABLE, then you can create tables in other accounts.
If you have that privilege, then you would prefix your commands with that account, for example:
create table SOMEONE_ELSE.my_table ( x int );
Otherwise, it is a case of actually creating a connection with the details of that other user.
Hope this helps.
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.)
I have an oracle database shared by both an internal application and our website.
I know very little about oracle so will explain things how I understand it..
The database has two users APPUSER and WEBUSER when logged in (using Oracle SQL Developer) as APPUSER you can see all the tables in the database. When logged in as WEBUSER you cannot see anything but a couple of procedures, the APPUSER cannot see these procedures.
One procedure starts with:
create or replace PROCEDURE "UPDATE_DETAIL"
(v_ref IN APPUSER.DETAILS.REFERENCE%TYPE
,v_desc IN APPUSER.DETAILS.DESCRIPTION%TYPE
...
Line 2 has a red squiggly with "PLS-00201: identifier APPUSER is not declared"
I believe it has the "APPUSER.TABLE.COLUMN" because WEBUSER does not have direct access to the tables.
I have executed GRANT ALL ON UPDATE_DETAIL TO APPUSERlogged in as WEBUSER, but that did not fix the issue, WEBUSER is the owner of the procedure, but does not have anything listed in the Grants list (I assume because owner just has the rights be default?)
The Dependencies list for the procedure is also empty, but cannot find how to manually add one to it.
Not sure what else to try to fix this error.
Thanks.
If you want a procedure owned by WEBUSER (and I believe from your description that UPDATE_DETAIL is owned by WEBUSER) to reference objects owned by APPUSER, you would need to grant WEBUSER privileges on those objects. For example, as APPUSER
GRANT SELECT ON appuser.details
TO webuser;
This assumes that WEBUSER only needs to SELECT from the APPUSER.DETAILS table. If your procedure needs to INSERT, UPDATE, or DELETE data in that table, then WEBUSER would need to be granted additional privileges on the APPUSER.DETAILS table. You'd need to make similar grants for every table in APPUSER that the WEBUSER user needs to reference.
I am a huge noob with Oracle right now. I was asked to import two databases into Oracle. I succeeded...sort of...I think. So these databases were exported with the user and when I imported the databases it created the user and all of the tables were attached to that user. Same thing for the second database. Lets just call the user for the first import USER1 and for the second db import USER2. USER1 has its own tables and USER2 has its own tables.
I want to create a user that can see all of those tables. so I don't have to login to one to access and manipulate its data and the other to do the same. I would like to create a USER3 that can see and manipulate USER1 and USER2's tables associated with each. I have tried a number of ways and just cannot seem to get this to work. Any help would be greatly appreciated.
Thanks
To allow USER3 to query a table owned by USER1:
GRANT SELECT ON USER1.tablename TO USER3;
You must run this for each table individually.
Other grants that you may need are INSERT, UPDATE and DELETE, e.g. to grant full control:
GRANT SELECT, INSERT, UPDATE, DELETE ON USER1.tablename TO USER3;
When you login as USER3, to query the table you normally need to specify the schema, e.g.:
SELECT * FROM USER1.tablename;
If you want to avoid having to specify the schema each time, you can use synonyms, e.g.:
(login as USER3)
CREATE SYNONYM tablename FOR USER1.tablename;
Now you can login as USER3 and run this:
SELECT * FROM tablename;
"I just don't understand why I have to do all that."
Users - or schemas - are the means Oracle uses for organising applications and enforcing governance. In a well-design application it is extremely unlikely that one schema would need to grant every privilege on all its objects to another user. Oracle recommends a policy of granting the minimum necessary set of privileges to other users. Doing this requires us to make choices and write discrete statements to grant specific privileges on particular objects.
I have tables in Schema A. I created views in Schema B using the tables in schema A.
I want to grant permissions to a user to select the data from view in Schema B.
For this to work i know we have to enable the grant option on tables in Schema A to user B.
But I want to do it in a single script (This script has to be in schema B). Is there a way to do this using the user name/password of schema A.
It's not unusual to want to have a single script to deploy a change. The thing is, such a script needs to be run by a power user, because it needs to have system privileges at the ANY level. This usually means a DBA account, preferably an application account but otherwise SYSTEM or SYS.
So the script you want would look like this:
grant select on user_a.t23 to user_b
/
grant select on user_a.t42 to user_b
/
create view user_b.v_69 as
select t23.col1, t42.col2
from user_a.t42
join user_a.t23
on (t42.id = t23.id)
/
grant select on user_b.v_69 to user_c
/
A common scenario is that we have a suite of individual scripts which have been written to be run by different users but which we now need to bundle up into a single deployment. The original scripts don't contain the schema names, and there are many good reasons why we wouldn't want to hardcode them in the scripts.
One way to build that master script is to use change the CURRENT_SCHEMA syntax:
alter session set current_schema=USER_A
/
#run_grants_to_userb.sql
alter session set current_schema=USER_B
/
#create_view69.sql
#run_grants_to_userc.sql
We still need a DBA user to run the master script. One advantage of switching the current schema is that it allows us to deploy objects like database links, which through a quirk of syntax cannot have the schema name in their declaration. One gotcha is that the user doesn't change, so a script which employs the USER pseudo-column may produce unwanted results.
Simply Run the query
GRANT INSERT, SELECT, UPDATE, DELETE ON TABLE1 TO SCHEMA2;
Only by connecting as user A at some point. You can still do it in one script if you really want to:
connect userA/passwordA
grant select on my_table to userB;
connect userB/passwordB
create view my_view as select * from userA.my_table;
Of course now you have a script lying around which exposes two sets of user credentials to anyone who can read it. So something to think hard about before doing in production, for example.
If you want other users to be able to select from the view, you don't need to grant explicit permissions on userA.my_table to them; as long as the view owner can see the underlying table, other users just need to be able to see the view. Which is often kinda the point (or one of them) as you can restrict the view to only expose selected data from the underlying table to the rest of the world. I assume you have a reason for not creating the view in schema A.
I'm not sure if you're really asking about granting select to user B with admin option so that user B can then grant select on user A's table to other people. If that's possible, it doesn't sound like a good idea, and isn't necessary for the view to work.
Let user A grant select on his tables to B and include the 'grant option'.
As user A:
GRANT select ON table TO user_b WITH GRANT OPTION;
Let user B grant select on his views to user A and include the 'grant option'.
As user B:
GRANT select ON view TO user_a WITH GRANT OPTION;
As user A:
GRANT select on user_b.view TO user_c;
This allows user A to pass this grant on to other users.