DBA_USER: create role test_2
DBA_user: grant create session, create any table, create any procedure to test_2;
grant succeeded.....
grant test_2 to new_user
now new_user:
create table items (item_number number(3) primary key,
item_name varchar2(40),
item_desp varchar2(20),
item_qty number(3));
Error: you have insufficient privilege
Exact Oracle error code would help, but first guess would be that new_user does not have privilege on SYSTEM (or other tablespace). It is not recommended to use SYSTEM tablespace in general, so let's create tablespace first.
Create separate tablespace for user :
create tablespace tbs_for_new_user
datafile 'tbs_nu.dbf' size 50m;
Then assign newly created tablespace to user as default
alter user "NEW_USER"
default tablespace "TBS_FOR_NEW_USER"
temporaty tablespace "TEMP"
account unlock; // if you did not unlock new_user account yet
alter user "NEW_USER" quota 50000m on TBS_FOR_NEW_USER;
alter user "NEW_USER" DEFAULT ROLE "TEST_2";
Then try to create table.
Related
I am the owner of a partitioned table (table_name) and I have granted the privileges to another user (user2).
GRANT All ON table_name TO user2
But whenn user2 want to create a partition of table_name :
create table table_name_1 partition of table_name for values from (0) to (10)
the next error appears:
must be owner of table table_name
Is there any way to allow this user to create a partition without making him the owner of this table?
Only the table owner (that extends to members of that role) or a superuser can create a partition. You cannot grant the privilege to anyone else unless you make them a member of the table owner:
GRANT my_user TO user2;
I have a postgres instance with a user root that has full admin privileges.
I have two databases db1 and db2.
For every database, I would like to have two users dbN_user and dbN_admin. dbN_user will be the used by my application, and dbN_admin will be used for migrations that change the table structure.
No rows are ever deleted by the application, and I would like to enforce that with user privileges.
db1_user should be able to connect to db1, and be able to SELECT, INSERT and UPDATE, but not DELETE.
db1_admin should have additional privileges to DELETE, CREATE TABLE, ALTER TABLE.
What are the SQL statements to set this up?
dbN_admin would be the owner of the objects, so that user would have all privileges automatically.
You need to GRANT the privileges for dbN_user on the tables and other objects themselves, not on the database.
Just add the correct GRANT statements after the CREATE TABLE statements in the SQL script that populates the database.
You need to GRANT the USAGE privilege on the schema that contains the objects to dbN_user as well.
There is the possibility to define default privileges in a database:
ALTER DEFAULT PRIVILEGES FOR dbN_admin
GRANT SELECT, INSERT, UPDATE ON TABLES
TO dbN_user;
This will grant the privileges automatically whenever dbN_admin creates a new table (but it does not affect tables created before the ALTER DEFAULT PRIVILEGES command).
admin:
create user db1_admin;
create schema app_relations;
alter schema app_relations owner to db1_admin;
app:
create user db1_user;
grant CONNECT ON DATABASE db1 to db1_user; --only if you have restricted connections on db previously
grant usage on schema app_relations to db1_user;
grant select,insert,update on all tables in schema app_relations to db1_user;
I am having a slight problem getting permissions to work the way I want them.
I have a role that should generally be allowed to SELECT everywhere, there are a bunch of members to this role. One of them should NOT be allowed to select from a certain table.
I thought this would be possible by granting role membership to the general reader role and revoking SELECT from the restricted table.
It seems the the permissions of the parent role apply and not the specific permissions. Is there a way around this without having to maintain the permissions of the more restricted role or am I applying the role concept in PostgreSQL in a wrong way?
Here's a sample script:
-- as superuser
CREATE DATABASE permission_test;
\c permission_test
CREATE ROLE r_general_select;
CREATE ROLE r_restricted_select IN ROLE r_general_select;
-- set the default permissions
ALTER DEFAULT PRIVILEGES IN SCHEMA "public" GRANT SELECT ON TABLES TO "r_general_select";
CREATE TABLE "open"(
id SERIAL,
payload TEXT
);
insert into "open"(payload) values ('test');
-- covered by default privileges
GRANT SELECT ON "open" TO PUBLIC;
-- Tests
-- this is good
SET ROLE r_general_select;
SELECT * FROM "open";
RESET ROLE;
-- this is good
SET ROLE r_restricted_select;
SELECT * FROM "open";
RESET ROLE;
CREATE TABLE "restricted" (
id SERIAL,
payload TEXT
);
insert into "restricted"(payload) values ('test');
-- the role and it's members should be able to read
GRANT SELECT ON "restricted" TO r_general_select;
-- except for this one!
REVOKE SELECT ON "restricted" FROM r_restricted_select;
-- Tests
-- this is good
SET ROLE r_general_select;
SELECT * FROM restricted;
RESET ROLE;
-- this should barf with a permission violation
SET ROLE r_restricted_select;
SELECT * FROM restricted;
RESET ROLE;
--- CLEANUP
DROP OWNED BY "r_restricted_select" CASCADE;
DROP ROLE r_restricted_select ;
DROP OWNED BY "r_general_select" CASCADE;
DROP ROLE r_general_select ;
In PostgreSQL, role permissions are purely additive. There is no way in such a model to revoke from a descendant, inheriting role a permission granted on the inherited one.
To fix this you need to change your permissions approach and base it on permissions that always occur together. I usually do this by looking at functional dependencies and operational dependencies together.
I try to grant specific privileges to my table "MEMBERS" in postgresql but nothing changes. More specifically I do this (through pgadmin console):
CREATE DATABASE login;
CREATE USER loginUser WITH PASSWORD 'xxxxxxxxxxxxx';
CREATE TABLE members (
id serial NOT NULL,
username varchar(30) NOT NULL
PRIMARY KEY(id)
)
ALTER USER loginuser WITH SUPERUSER;
ALTER TABLE members OWNER TO loginuser;
GRANT SELECT, UPDATE, INSERT, DELETE ON members TO loginuser;
The query is returned successfully but when I check the table's privileges through the pgadmin gui all of them are selected.
What am I missing?
By default, a table's owner has full privileges on it. If you want "loginuser" to have only select, update, insert, and delete privileges, you would normally revoke all privileges first, then grant just those four.
revoke all on members from loginuser;
grant select, update, insert, delete on members to loginuser;
This will appear to work for you, but it really won't. A database superuser can revoke privileges from a table's owner. But you've made "loginuser" a superuser. Whatever privileges you revoke, "loginuser" can just grant to herself.
You need to think more carefully about what you're trying to accomplish here.
When I give the command to drop a user i.e. DROP USER 'username' cascade,
Does it deletes all the tablespace and datafiles used by that particular user.
If not, what is the command to delete all the tablespace / datafiles / disk space that were used by that particular user.
After dropping the user, you need to, for each related tablespace, take it offline and drop it. For example if you had a user named 'SAMPLE' and two tablespaces called 'SAMPLE' and 'SAMPLE_INDEX', then you'd need to do the following:
DROP USER SAMPLE CASCADE;
ALTER TABLESPACE SAMPLE OFFLINE;
DROP TABLESPACE SAMPLE INCLUDING CONTENTS;
ALTER TABLESPACE SAMPLE_INDEX OFFLINE;
DROP TABLESPACE SAMPLE_INDEX INCLUDING CONTENTS;
DROP USER---->
DROP USER USER_NAME CASCADE;
DROP TABLESPACE---->
DROP TABLESPACE TABLESPACE_NAME INCLUDING CONTENTS AND DATAFILES;
You can check which table space is used by which user with the following query.
SELECT USERNAME, DEFAULT_TABLESPACE FROM DBA_USERS;
You can also see the list of table spaces by looking at the following tables
DBA_TABLESPACES
USER_TABLESPACES