I am the first user of Oracle Database.
Now, I want to create a DB schema called ERDB.
I need to create the ERDB user and granting appropriate privileges to the ERDB user on SQL script file.
CREATE USER dmuser IDENTIFIED BY password
DEFAULT TABLESPACE USERS
TEMPORARY
TABLESPACE TEMP
QUOTA UNLIMITED ON USERS;
GRANT CREATE JOB TO dmuser;
GRANT CREATE MINING MODEL TO dmuser;
GRANT CREATE PROCEDURE TO dmuser;
GRANT CREATE SEQUENCE TO dmuser;
GRANT CREATE SESSION TO dmuser;
GRANT CREATE SYNONYM TO dmuser;
GRANT CREATE TABLE TO dmuser;
GRANT CREATE TYPE TO dmuser;
GRANT CREATE VIEW TO dmuser;
GRANT EXECUTE ON ctxsys.ctx_ddl TO dmuser;
but the error happens, SQL Error: ORA 01031 insufficient privileges;
please help me.
The Oracle documentation clearly states the following:
Prerequisites
You must have the CREATE USER system privilege.
Connect as SYSTEM, no need of SYSDBA and then execute:
CREATE USER user IDENTIFIED BY password
Similarly, execute other command to create the tablespaces and required grants etc.
On a side note, regarding SYSDBA:
Never ever use SYS (or SYSDBA) but for maintenance purpose (startup, shutdown, backup, recover)
SYS/SYSDBA is special
SYS/SYSDBA is Oracle proprietary (try to open a SR/TAR starting with "i did that with SYS/SYSDBA" and you'll see the immediate answer)
SYS/SYSDBA does not act like any other user
When you use SYS/SYSDBA Oracle deactivates some code path and activates others
Whatever you do with SYS/SYSDBA will neither validate nor invalidate the same thing with any other user.
NEVER EVER use SYS/SYSDBA for anything that can be done by another
user. Use SYS/SYSDBA ONLY for something that can't be done by someone
else.
Related
I have an application schema U32_C5 and another schema MIG_SRC which has some tables and then we have a ROLE RO_ROLE on which we have some grants of tables from Schema U32_C5.
The RO_ROLE is assigned to another Schema MRGO_RO which is Read Only.
Here I need to grant select on tables from MIG_SRC to MRGO_RO catch here is that the process which and from where I can include these grants is run from application schema U32_C5 in production so when I tried to to something like below it says table or view does not exists (which seems to be obvious)
execute Grant from U32_C5
grant select on MIG_SRC.MOBILE_CELLPHONE_PAIRINGS to MRGO_RO;
Another way which I think of is creating DB link on MRGO_RO for MIG_SRC Schema but it enables read/write operation as well on MIG_SRC tables which is not allowed on production.
DB Links is present on U32_C5 Schema for MIG_SRC Schema
So looking for a way to accomplish above task without creating DB Link any suggestion is welcome.
Sample Script of requirement what I want to achieve Please Remember I cannot and do not want Login to MIG_SRC and only way I am looking for is to do it by using U32_C5 and without DBA HELP
A RO ROLE Created by DBA's
Create role RO_ROLE;
/* Create application schema, table inside it and grant select on it to RO_ROLE*/
CREATE USER U32_C5 IDENTIFIED BY U32_C5 DEFAULT TABLESPACE;
GRANT ALTER SESSION TO U32_C5;
GRANT CREATE SESSION TO U32_C5;
GRANT CREATE database link TO U32_C5;
GRANT CREATE table TO U32_C5;
create table U32_C5_test_tab (id number);
grant select on U32_c5.U32_C5_Test_tab to RO_ROLE;
/* Create Read Only schema, grant RO_ROLE to it */
CREATE USER mrgo_ro IDENTIFIED BY mrgo_ro DEFAULT TABLESPACE;
GRANT ALTER SESSION TO mrgo_ro;
GRANT CREATE SESSION TO mrgo_ro;
grant ro_role to mrgo_ro;
/* Create SRC schema, table inside it */
CREATE USER MIG_SRC IDENTIFIED BY MIG_SRC DEFAULT TABLESPACE;
GRANT ALTER SESSION TO MIG_SRC;
GRANT CREATE SESSION TO MIG_SRC;
GRANT CREATE database link TO MIG_SRC;
GRANT CREATE table TO MIG_SRC;
create table mig_src_test_tab (id number);
/* login to Apllication Schema U32_C5 */
sqlplus U32_C5/U32_C5#SID
grant select on mig_src.mig_src_test_tab to mrgo_ro; -- for me it gives error here at this step table or does not exist
/* login to Read Only Schema mrgo_ro */
sqlplus mrgo_ro/mrgo_ro#SID
select * from mig_src.mig_src_test_tab;
or
select * from mig_src_test_tab;
If I understood you correctly, then WITH GRANT OPTION is what you're missing.
Once someone (A) grants privileges on their own objects to someone else (B), and that (B) has to "forward" those privileges to (C), then it is the WITH GRANT OPTION that helps.
Documentation says:
Specify WITH GRANT OPTION to enable the grantee to grant the object privileges to other users and roles.
Restriction on Granting WITH GRANT OPTION You can specify WITH GRANT OPTION only when granting to a user or to PUBLIC, not when granting to a role.
It means that you should grant privileges directly, not via role. That fact doesn't have to be a drawback because of named PL/SQL procedures, where privileges acquired via roles won't work anyway, so you might end up in direct grants anyway.
Other option - which you might consider - is related to what you said:
when I tried to to something like below it says table or view does not exists
If you created a synonym for those tables, then you wouldn't get such an error.
Database link isn't an option, as you said - by using it, you have full access (as you have to know username/password to create the DB link, and that isn't really read only access).
Is there a way I can grant truncate permission to a user without altering privileges in SQL Server?
The minimum permission required is ALTER on table_name. TRUNCATE TABLE permissions default to the table owner, members of the sysadmin fixed server role, and the db_owner and db_ddladmin fixed database roles, and are not transferable. However, you can incorporate the TRUNCATE TABLE statement within a module, such as a stored procedure, and grant appropriate permissions to the module using the EXECUTE AS clause.
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'CompanyDomain\SqlUser1'
AS
SELECT user_name();
Source
You can go through this official documentation.
Create a test Login and User id then grant it execute permission on the stored procedure Truncate_Table_Loner. This id will be used to perform the truncate.
-- Grant Execute Permission
-- Setup ID on Database with Connect permission
USE master
GO
CREATE LOGIN [test_user_id] WITH PASSWORD = 'JustConnect123';
GO
USE TestSQL
GO
CREATE USER [test_user_id] FOR LOGIN [test_user_id];
GO
-- Grant Permission
GRANT EXECUTE ON dbo.Truncate_Table_Loner TO [test_user_id];
GO
I am a big fan of PostgreSQL but can't figure out one aspects of it's built in user management.
My problem is that I have set up pgAdmin and will have some non-developers manually update data in some specific tables. For this reason I have created a new user called "admin" and are looking to restrict this users rights.
I have tried to delete all rights for the user with the following query (from another user):
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM admin;
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public FROM admin;
REVOKE ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public FROM admin;
The above did lead to the following error when I wrote a simple SELECT statement from the user admin on a table called "crap": ERROR: permission denied for relation crap.
But what I was able to do with the user admin which by now shouldn't have any rights was the following: DROP TABLE crap; which worked!?
I am really surprised by this. This user is not a Postgres superuser. How can I remove this right to drop tables for a specific user?
You're one level off in hierarchy for the permissions.
REVOKE ALL PRIVILEGES FROM SCHEMA public FROM <role_name>;
You were affecting permissions within the table. You must also go one level up to the schema as well to protect create/drop access. You may also want to revoke access at the database level as well to protect the schema.
REVOKE ALL PRIVILEGES FROM DATABASE <database_name> FROM <role_name>;
You could also simply remove the user. Alternatively you could simply disable that user's ability to login.
ALTER ROLE <role_name> SET NOLOGIN;
If these don't work for you, you can go down a somewhat more complicated route and make an event trigger that watches for DROP TABLE events, compares against the role, and either allows it to continue or aborts the transaction.
CREATE OR REPLACE FUNCTION no_admin_drop()
RETURNS event_trigger LANGUAGE plpgsql AS $$
BEGIN
IF CURRENT_USER = 'admin'::regrole THEN
RAISE EXCEPTION 'command is disabled';
END IF;
END;
$$;
CREATE EVENT TRIGGER no_admin_drop ON sql_drop
EXECUTE FUNCTION no_admin_drop();
I have created a sample application to get schema of all objects and generate SQLfile, so I simply created two user, user 'SYSTEM' and 'SCOTT' , and user SYSTEM grant all privileges to access some of tables,views,function etc. to user SCOTT,
for grant privileges to user SCOTT use following oracle query
GRANT ALL ON table_name to username
But the problem is this query is not working for trigger and synonyms.
so anyone please suggest me how can I grant privileges on triggers and synonyms to user SCOTT.
But the problem is this query is not working for trigger and synonyms. so anyone please suggest me how can I grant privileges on triggers and synonyms to user SCOTT.
TRIGGER - You cannot t give grants for trigger. There is no such thing. Triggers fire automatically whenever the trigger event is done on the table on which the the trigger is created. You only need to grant privilege on the table.
SYNONYM - You just create a synonym for the schema.table and grant privilege on the table such that other users doesn't have to fully qualify the table and just use the synonym instead.
Does the following command effectively give the user, "MyUser," permission to execute ALL stored procedures in the database?
GRANT EXECUTE TO [MyDomain\MyUser]
SQL Server 2008 and Above:
/* CREATE A NEW ROLE */
CREATE ROLE db_executor
/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO db_executor
For just a user (not a role):
USE [DBName]
GO
GRANT EXECUTE TO [user]
SQL Server 2005 introduced the ability to grant database execute permissions to a database principle, as you've described:
GRANT EXECUTE TO [MyDomain\MyUser]
That will grant permission at the database scope, which implicitly includes all stored procedures in all schemas. This means that you don't have to explicitly grant permissions per stored procedure.
You can also restrict by granting schema execute permissions if you want to be more granular:
GRANT EXECUTE ON SCHEMA ::dbo TO [MyDomain\MyUser]
In addition to the answers above, I'd like to add:
You might want to grant this to a role instead, and then assign the role to the user(s).
Suppose you have created a role myAppRights via
CREATE ROLE [myAppRights]
then you can give execute rights via
GRANT EXECUTE TO [myAppRights]
to that role.
Or, if you want to do it on schema level:
GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]
also works (in this example, the role myAppRights will have execute rights on all elements of schema dbo afterwards).
This way, you only have to do it once and can assign/revoke all related application rights easily to/from a user if you need to change that later on - especially useful if you want to create more complex access profiles.
Note: If you grant a role to a schema, that affects also elements you will have created later - this might be beneficial or not depending on the design you intended, so keep that in mind.