We're looking to set up a user in our Vertica database that can see certain system tables, (projections, projection_storage and views), but we don't want this user to be a dbadmin, because we don't want them to have write privileges on these tables. I've tried using GRANT statements to give a regular user access to these tables, but that doesn't seem to work. Each user can only see their own own records in those tables. Is there a way to set up a user as I describe, or do we need to have this user be a dbadmin?
Our use case is that we need a user that can get a list of the schemas that exist in our database and iterate through each schema, gathering information to store in one central location. If our user is granted usage on the individual schemas, then they can get a list of those schemas, but they aren't able to access the necessary records in the projection_storage and views tables.
Thank you!
Granting USAGE on the schema to the user or role is not enough for users to see its projections in projection_storage table. If the user or the role has SELECT access on the table, then projections for those tables can be viewed in projection_storage. I am in Vertica 7.1, and I was able to view projection records by granting SELECT permission just to the role instead of granting to individual user ID.
If the user does not need to access tables but needs to list out tables in the schema for some reporting purpose, one option would be to periodically dump the content of projection_storage to a different table and grant proper privileges on this table to the user.
Just for the sake of maintaince you should create database roles !! and then give acces to those roles to your users . Other-wise the maintainance will be hell to you !!
Normally, I just give a user USAGE on a schema. And then "GRANT SELECT on to ;"
Do they have INSERT permissions on those tables?
Granting select access to the role on the table , does not grant complete access to metadata tables like projection_storage . This seems to be a bug. In order to get complete access select needs to be granted to individual user id.
You can follow the below steps to create a user with select privileges to a schema .
I ll follow this with a example ,In my test database I have a schema 'sid' with a table 'student_table'.
1) Login as a admin on your database .
[dbadmin#localhost bin]$ vsql -u
User name: dbadmin
Password:
2) Create the user with a password
dbadmin=> create user test identified by 'R';
CREATE USER
3) Give the newly created user a Grant for the usage on the database.
dbadmin=> Grant ALL on database vertica to test;
GRANT PRIVILEGE
4) You can then grant the user the Usage to the schema
dbadmin=> Grant Usage on Schema sid to test;
GRANT PRIVILEGE
5) Finally provide the select grant to the user on the table .
dbadmin=> Grant select on sid.student_table to test ;
GRANT PRIVILEGE
dbadmin=> \q
6) Login with the new user 'test' , You will be able to access both projection storage and
your table sid.student_table
[dbadmin#localhost bin]$ vsql -u
vsql: Warning: The -u option is deprecated. Use -U.
User name: test
Password:
Welcome to vsql, the Vertica Analytic Database interactive terminal.
test=> select * From sid.student_table;
Student_ID | Last_name | First_Name | Class_Code | Grade_pt
------------+-----------+------------+------------+--------------------
9999 | T_ | S% | PG | 98.700000000000000
(1 row)
test=> select * From projection_storage;
-[ RECORD 1 ]-----------+-----------------------------------------
node_name | v_vertica_node0001
projection_id | 45035996273836526
projection_name | Student_Table_DBD_1_rep_tet1_v1_node0001
projection_schema | sid
projection_column_count | 6
row_count | 9
used_bytes | 375
wos_row_count | 0
wos_used_bytes | 0
ros_row_count | 9
ros_used_bytes | 375
ros_count | 1
anchor_table_name | Student_Table
anchor_table_schema | sid
anchor_table_id | 45035996273756612
Related
so I want to grant an update to a user account like this
grant update on stuff to admin1;
but after I select * from admin1.stuff, an error "table or view does not exist". how can I see the data table in the user account
Presume you're currently connected as user nanatua and ran
grant update on stuff to admin1;
It lets user admin1 to update values in table stuff you own. Nothing else.
If you want to let it query (select) data from that table, you have to grant it:
grant select on stuff to admin1;
Then connect as admin1 and run
select * from nanatua.stuff;
Not vice versa! as you tried to; command you used (select * from admin1.stuff) means that user admin1 owns the table, but it is not.
I'm using Oracle 11g(11.2.0.1.0). I created about 20 tablespaces and users. And the data came by [Tools] - [Database Copy] on Oracle SQL Developer.
Somehow I found that a user is using SELECT query on the table from another schema. I want to prevent it for security. How should I change my grant options?
I read "Oracle Database Security Guide 11g Release 2(11.2)", but couldn't find the solution clearly.
Here are my creating and granting queries.
create user [USER_NAME]
identified by [PASSWORD]
default tablespace [TABLESPACE_NAME]
temporary tablespace TEMP;
grant create session,
create database link,
create materialized view,
create procedure,
create public synonym,
create role,
create sequence,
create synonym,
create table,
drop any table,
create trigger,
create type,
create view to [USER_NAME];
alter user [USER_NAME] quota unlimited on [TABLESPACE_NAME];
And here is the SELECT result of session_privs on a user.
SQL> SELECT * FROM session_privs;
PRIVILEGE
--------------------------------------------------------------------------------
CREATE SESSION
CREATE TABLE
DROP ANY TABLE
CREATE SYNONYM
CREATE PUBLIC SYNONYM
CREATE VIEW
CREATE SEQUENCE
CREATE DATABASE LINK
CREATE ROLE
CREATE PROCEDURE
CREATE TRIGGER
PRIVILEGE
--------------------------------------------------------------------------------
CREATE MATERIALIZED VIEW
CREATE TYPE
13 rows selected.
I want to prevent a user from querying SELECT on other schemas.
For example, the following query
-- connected with USER1
SELECT *
FROM USER2.table1;
should make an error like:
ERROR: USER1 doesn't have SELECT privilege on USER2.
Edited:
Use appropriate terms (changed some words from tablespace to schema)
Add SELECT result of session_privs on a user
Add the method of how the data came by.
It was my fault. I missed that I had added some roles.
To copy data using Oracle SQL Developer, I added predefined roles to users. The roles were exp_full_database and imp_full_database.
According to Oracle Database Security Guide: Configuring Privilege and Role Authorization, exp_full_database contains these privileges:
SELECT ANY TABLE
BACKUP ANY TABLE
EXECUTE ANY PROCEDURE
EXECUTE ANY TYPE
ADMINISTER RESOURCE MANAGER
INSERT, DELETE, UPDATE ON SYS.INCVID, SYS.INCFIL AND SYS.INCEXP
and roles:
EXECUTE_CATALOG_ROLE
SELECT_CATALOG_ROLE
Those roles are not required now. So the answer is removing them from users.
REVOKE exp_full_database, imp_full_databsae FROM USER1;
And I get the result I wanted.
-- connected with USER1
SELECT * FROM USER2.TABLE1;
ERROR at line 1:
ORA-01031: insufficient privileges
Using Oracle 12c, I have a role which I have granted basic CRUD operations to using Oracle SQL Developer. The problem is, users of the group can not see the list of tables in Oracle SQL Developer. All they see is the branch that shows a tables node but there is no plus sign to expand and see the tables for the one schema they need to work with. What other privilege needs to be granted to the group so they can see all the table nodes for their schema when using Oracle SQL Developer? Thanks in advance.
If I understood you correctly, you
created a role
granted certain privileges to that role
created bunch of users
granted role (from step 1) to those users
but they still don't see anything.
If that's so, they won't see anything regardless of what you grant - it is because they don't have those objects in theirs schemas.
What you (or they) should/could do is to precede table name with owner name while selecting data from those tables. Suppose that there's a table named EMPLOYEE and your users want to select data from it - they should run select * from robertcode.employee (presuming that user robertcode owns that table)
Although it works, users won't be happy because they don't know table names. Therefore, create a script which they will run in their schemas - that script will create synonyms to your tables.
In order to do that, write query which will create query:
SQL> select 'create synonym ' || table_name || ' for ' || table_name ||';'
2 from user_tables;
'CREATESYNONYM'||TABLE_NAME||'FOR'||TABLE_NAME||';'
--------------------------------------------------------------------------------
create synonym EMP for EMP;
create synonym BONUS for BONUS;
create synonym SALGRADE for SALGRADE;
create synonym DEPT for DEPT;
Copy/paste all those create synonym ... statements into an e-mail message and let them create synonyms for themselves.
They still won't see anything under the Tables node (because those users don't have tables (until they create them in their own schema), but will see something in Synonyms.
I'm wondering if there's a way to set up a user with dba-like read-only privileges.
In my use-case, I'm trying to fetch some data from of schema from SYS.ALL_ARGUMENTS table.
I'm using this statements to create my user:
CREATE USER bbb IDENTIFIED BY bbb;
/
GRANT CREATE SESSION TO bbb;
/
grant select any table to bbb WITH ADMIN OPTION;
/
grant select on SYS.ALL_ARGUMENTS to bbb;
when I try to run the following statement to fetch data of HR schema:
SELECT * FROM SYS.ALL_ARGUMENTS a WHERE a.OWNER = 'HR' ORDER BY SEQUENCE;
I get nothing. If I set my user with DBA role or IMP_FULL_DATABASE role, i manage to get this data but then my user has privileges I don't want him to have.
Privilege SELECT ANY TABLE does not include dictionary views. Run
GRANT SELECT ANY DICTIONARY TO bbb;
in order to grant full read access.
I confused lot in oracle about schema, user and functional id. Let consider my two different cases
Case I :
Let us consider SCOTT#ORCL.If we think SCOTT is user. while creating user alone it ll create a schema. Correct me If i am wrong. In this case while we were creating SCOTT user alone SCOTT schema was created. Suppose If we create another schema say X . Is this possible to SCOTT user owns X schema ?
Case II :
Let us consider SCOTT#ORCL.If we think SCOTT is schema alone i-e which is created by schema command alone. If it is so then what is the use of schema w/o any user who is going to own it.
I heard oracle function ID is one which will connect several user/schema(i don't know whether I can put schema/user here ) in a data base. is there is difference b/w oracle functional ID with user/schema ?
Many people find this topic confusing, because we tend to bandy around USER and SCHEMA interchangeably, when they are in fact separate if related entities.
A schema is the collection of database objects owned by a user. When we create a user we create their schema at the same time. Initially their schema is empty.
It is easy to demonstrate that USER and SCHEMA are distinct, because we change the current schema in the session. This just means we can reference objects in another user's schema without prefixing them with the owner's name.
SQL> desc t1
Name Null? Type
----------------------------------------- -------- -------------
ID NUMBER
SQL> alter session set current_schema=APC
2 /
Session altered.
SQL> desc t1
ERROR:
ORA-04043: object t1 does not exist
SQL> sho user
USER is "X"
SQL>
In this case, either APC doesn't have a table called T1 or he hasn't granted it to X. The only way X can see her own table is to prefix it with her own name, or switch the current schema back to herself.
To answer your first question, the schema always has the same name as the user. So it is not possible for SCOTT to own schema X; schema X is owned by user X.
To answer your second question, it is impossible to create a schema without a user.
True, there is a CREATE SCHEMA command, but this requires the prior creation of the user. It is actually not creating a schema but creating several database objects. In effect it is more of a ADD OBJECTS TO SCHEMA command.
SQL> conn sys as sysdba
Enter password:
Connected.
SQL> create user x identified by x
2 default tablespace users quota 10m on users
3 /
User created.
SQL> grant create session, create table to x
2 /
Grant succeeded.
SQL> conn x/x
Connected.
SQL> create schema authorization x
2 create table t1 (id number)
3 create table t2 (id number)
4 /
Schema created.
SQL> select table_name from user_tables
2 /
TABLE_NAME
------------------------------
T1
T2
SQL>
The CREATE SCHEMA command is pretty limited: we can create tables, views and indexes, and grant privileges on objects. The advantage of it is simply that we can create several objects in a single transaction, so that all the creates are rolled back if one fails. This is not possible when we run each create statement separately.
Not sure what you're thinking off when you mention "function ID". It's not a standard piece of Oracle functionality.
This does not define the difference between an owner and schema.
But I have always struggled with the idea that I create N number of users....when I want each of these users to "consume" (aka, use) a single schema.
This guy shows how to do this (have N number of users...get "redirected" to a single schema.
I will paste his code as well, on the off-chance the URL link dies in the future.
http://www.oracle-base.com/articles/misc/schema-owners-and-application-users.php
He has a second "synonym" approach. But I am only pasting the CURRENT_SCHEMA version.
AGAIN, I take NO credit for this. I just hate when someone says "your answer is at this link" and BOOM, the link is dead. :<
......................................................
(from http://www.oracle-base.com/articles/misc/schema-owners-and-application-users.php)
CURRENT_SCHEMA Approach
This method uses the CURRENT_SCHEMA session attribute to automatically point application users to the correct schema.
First, we create the schema owner and an application user.
CONN sys/password AS SYSDBA
-- Remove existing users and roles with the same names.
DROP USER schema_owner CASCADE;
DROP USER app_user CASCADE;
DROP ROLE schema_rw_role;
DROP ROLE schema_ro_role;
-- Schema owner.
CREATE USER schema_owner IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO schema_owner;
-- Application user.
CREATE USER app_user IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
GRANT CONNECT TO app_user;
Notice that the application user can connect, but does not have any tablespace quotas or privileges to create objects.
Next, we create some roles to allow read-write and read-only access.
CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;
We want to give our application user read-write access to the schema objects, so we grant the relevant role.
GRANT schema_rw_role TO app_user;
We need to make sure the application user has its default schema pointing to the schema owner, so we create an AFTER LOGON trigger to do this for us.
CREATE OR REPLACE TRIGGER app_user.after_logon_trg
AFTER LOGON ON app_user.SCHEMA
BEGIN
DBMS_APPLICATION_INFO.set_module(USER, 'Initialized');
EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER';
END;
/
Now we are ready to create an object in the schema owner.
CONN schema_owner/password
CREATE TABLE test_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT test_tab_pk PRIMARY KEY (id)
);
GRANT SELECT ON test_tab TO schema_ro_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON test_tab TO schema_rw_role;
Notice how the privileges are granted to the relevant roles. Without this, the objects would not be visible to the application user. We now have a functioning schema owner and application user.
SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
Name Null? Type
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
DESCRIPTION VARCHAR2(50)
SQL>
This method is ideal where the application user is simply an alternative entry point to the main schema, requiring no objects of its own.