I am currently importing a dump file inside RDS Oracle 12C instance using impdp command.
Prior to that it is required to create few users & grant them required privileges.
I have following statements that I use on other non-rds databases.
GRANT UNLIMITED TABLESPACE TO "USERNAME"
GRANT "RESOURCE" TO "USERNAME"
GRANT "CONNECT" TO "USERNAME"
GRANT "EXECUTE_CATALOG_ROLE" TO "USERNAME"
When I run these prior to import, these commands return grant succeeded.
Now, when I run impdp, I get following errors in log:
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
ORA-31685: Object type SYSTEM_GRANT:"USRNAME" failed due to insufficient privileges.
Failing sql is:
GRANT UNLIMITED TABLESPACE TO "USERNAME"
ORA-39083: Object type ROLE_GRANT failed to create with error:
ORA-01924: role 'CONNECT' not granted or does not exist
Failing sql is:
GRANT "CONNECT" TO "USERNAME"
Same for other privileges as well.
I am running these commands using admin user that was created while spinning up the instance.
I have seen there's a different way of granting in AWS RDS on this link
How do I map that with what I'm trying to achieve here?
I'd suggest you NOT to use RESOURCE and CONNECT roles. These were popular back in 1990s as they contained the most common privileges one might need. However, best practice says that you should grant only privileges that are required for a certain user.
CONNECT nowadays contains only CREATE SESSION. RESOURCE contains several CREATE something privileges (table, procedure, trigger, ...) (query DBA_SYS_PRIVS to see them all). Do you really need CREATE CLUSTER? If not, well, don't grant it.
Try to add those privileges separately:
grant create session to username;
grant create table to username;
grant unlimited tablespace to username;
grant *whichever additional privilege USERNAME requires*;
Finally, just in case you didn't read it, this is the Importing Data into Oracle on Amazon RDS documentation, have a look; perhaps you'll find something useful.
Your case deals with a very specific situation Oracle Database permission to user. To grant a ALREADY EXISTING USER such a privilege (QUOTA UNLIMITED) is has to be done with this command:
ALTER USER xxxx_userName QUOTA UNLIMITED ON yyyy_tablespaceName;
Related
I have a share(i.e. shareTest_share) in accountAdmin role in one of my reader accounts in snowflake.
Now I want to create a database from this, but from sysAdmin role.
The statement for creating database is:
CREATE or replace DATABASE shareTest_db FROM SHARE mukulanalytics.shareTest_share
This is giving permission issue since I am trying to execute it from the sysAdmin role instead of accountAdmin role which has the access to shareTest_share share.
Error:
SQL access control error: Insufficient privileges to operate on foreign share 'SHARETEST_SHARE'
How can I create a database from share in a different role with share in another role?
You will have to grant the IMPORT SHARE privilege to SYSADMIN/any other users
use role accountadmin
grant import share on account to sysadmin
use role sysadmin
create database TEST from share <>
https://docs.snowflake.com/en/user-guide/security-access-privileges-shares.html
the privileges required to achieve this are described here: https://docs.snowflake.com/en/user-guide/security-access-privileges-shares.html
Executed this statement while using ACCOUNTADMIN role:
GRANT CREATE WAREHOUSE ON ACCOUNT TO ROLE DATABASE_ADMIN;
However when I use DATABASE_ADMIN role and then execute create warehouse statement, it gives me following error:
SQL access control error: Insufficient privileges to operate on account 'XXXX'
What am I missing here?
The most common problem I've run into with this is that the Snowflake web IDE actually has two role selectors. The one in the top right is your role when dealing with the interface, but each sheet has their own role as well.
Try adding an explicit use statement before your create.
use role DATABASE_ADMIN;
create warehouse MY_WAREHOUSE ...;
I am running a schema compare between two databases to make sure their schemas are identical. On most of the tables, the only thing different is permission.
Names changed to protect innocent databases. "Otherone" is the sql login I am currently using, that has additional rights compared to most users.
Does AS [principal] part matter?
I tried to change it but got an error about rights.
I'm not new to sql but I am new to the security side of it.
For example
Database A:
GRANT INSERT ON OBJECT::[someschema].[sometable] TO [somerole]
AS DBO
Database B:
GRANT INSERT ON OBJECT::[someschema].[sometable] TO [somerole]
AS OTHERONE
AS Specifies a principal from which the principal executing this query derives its right to grant the permission.
The grantor (or the principal specified with the AS option) must have either the permission itself with GRANT OPTION, or a higher permission that implies the permission being granted.
If you are using the AS option, the following additional requirements apply:https://learn.microsoft.com/en-us/sql/t-sql/statements/grant-object-permissions-transact-sql?view=sql-server-2017
Someone created a database and I am a super user in PG Admin. When I tried to access the database tables by clicking on it, I received the error message "permission denied for relation table_name". It's a table for the Mayan database. I tried all kinds of methods, but I am unfamiliar with this and not sure how to go about doing it. I opened the SQL editor and entered the GRANT commands to grant myself access, but I keep getting "permission denied". I am using PG Admin.
Can anyone tell me how can I be granted access to the table?
To access a table you have to grant privileges to the tables with GRANT. First enter to the database and open a SQL editor then execute one of the next queries:
-- For all privileges
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO user
-- For viewing privileges
GRANT SELECT ON ALL TABLES IN SCHEMA public TO user
Note that you have to specify the schema.
I am deploying a database in postgreSQL and I created a user that just will be able to execute certain functions.
I revoked all privileges from the user i just created and granted connect privileges executing:
REVOKE ALL PRIVILEGES ON DATABASE <database> FROM my_user;
REVOKE ALL PRIVILEGES ON SCHEMA public TO my_user;
GRANT CONNECT ON DATABASE <database> TO my_user;
But when i connect to the database with this user, i am able to read all table structures and all function source codes. Is there a way to hide it from this user?
I take the chance to make another question: I want to just execute functions (which may include select, insert or update on database tables) with this user, but I don't want to grant privileges on select, update or delete on tables.
I am using "SECURITY DEFINER" and then I grant execution, but I think it may be a little insecure. Am I right? is there any other way to do it?
Thanks in Advance.
Lamis
There's no way to hide the system catalogues from a user in PostgreSQL. If a user can't access the catalogues then they can't locate any other database objects.
If you really can't afford to let them see the structure of the db, you'll need to prevent them connecting. Build some sort of middle layer with a simple API that calls the db.
SECURITY DEFINER is the standard way to provide limited access at a higher privilege level. You have to be careful with any function arguments that can end up in a dynamic query though. That's the same "bobby tables" issue as with any dynamic sql building though.
How about
REVOKE SELECT ON pg_namespace FROM my_user;
REVOKE SELECT ON pg_catalog.pg_database FROM my_user;
You won't be able to see anything, but you'll be able to make queries if you know the namespace and table name.