I have two schema called master and transaction.
In master one table called - BCC_TM_CITY
In transaction one procedure called PR_GETCITIES.
In this procedure table BCC_TM_CITY used like this
select * from master.BCC_TM_CITY;
My problem is, recently I dropped the table and added again in master. After that, in PR_GETCITIES procedure, the place referring table (BCC_TM_CITY) am getting error ( Insufficient privilege ). Now I want to know how to give privilege to this table in SQL developer and want to solve this error.
Please any help me to solve this problem.
You need to GRANT the required privileges on the table to the user.
For example, if you want to grant SELECT, INSERT, UPDATE, and DELETE privileges, you would run the following GRANT statement:
GRANT SELECT, INSERT, UPDATE, DELETE ON BCC_TM_CITY TO master;
If you want to grant only SELECT access on the table, but to all the users, you could grant the privileges to the public keyword. For example:
GRANT SELECT ON BCC_TM_CITY TO public;
See more examples and usage here.
Related
I have a PostgreSQL DB user "limited_user" and want to give SELECT permission on one table ONLY.
GRANT CONNECT ON DATABASE "db1" TO limited_user;
GRANT SELECT ON TABLE users to limited_user;
What happens is that when I try \dt , the user can see all the other tables in this db1, while he can perform SELECT operation to table "user" as I gave permission. How can I revoke access access to the user so that he can not see other tables and just one table?
You can't, at least not in any straightforward way that I am aware of.
Tables exist within the schema namespace, and schemas exist within the database. To give access to a user on a particular table means you must also give that user the USAGE permission on the schema to which the table belongs. USAGE does not grant permissions on the tables themselves, only the the schema in question. But table definitions are part of the schema, so USAGE does allow the user to see table names (and the columns too).
But if there are other tables in the same schema, the user will not be able to SELECT from those tables unless you also GRANT SELECT on those tables, even though they will be able to see that they exist.
This answer gives a pretty clear explanation of the permission system.
Edit to add:
One way to achieve a similar outcome would be like this (using psql):
sec_schema=# REVOKE ALL ON ALL TABLES IN SCHEMA sec_schema FROM restricted_user;
REVOKE
sec_schema=# REVOKE USAGE ON SCHEMA sec_schema FROM restricted_user;
REVOKE
sec_schema=# CREATE SCHEMA new_schema;
CREATE SCHEMA
sec_schema=# GRANT USAGE ON new_schema TO restricted_user;
GRANT
sec_schema=# CREATE VIEW new_schema.secret_view AS SELECT * from sec_schema.secret_table;
CREATE VIEW
sec_schema=# GRANT SELECT ON new_schema.secret_view TO restricted_user;
GRANT
This will remove all access to the schema sec_schema for user restricted_user, but then creates new_schema and new_schema.secret_view which is a cover view over sec_schema.secret_table. After the GRANT SELECT, the user will be able to read the data from table sec_schema.secret_table through the view, but they will not be able to see any objects in sec_schema.
I want to create three SQL Server database roles.
That can CREATE, ALTER and EXECUTE all stored procedures in database
That can only EXECUTE all stored procedures in database
That have no access to any stored procedures in database
I have created the roles, but I'm facing issues while REVOKE their permissions.
I have executed
REVOKE CREATE PROCEDURE TO [ROLE NAME]
to revoke the permissions to create the procedure and it executed successfully.
But I got error while executing this statement:
Error: Incorrect syntax near 'ALTER'.
I am very new to SQL server role rights so I might be completely wrong with my approach.
Please guide me to achieve my goal in correct way.
Thanks
From the documentation Create a Stored Procedure:
Permissions
Requires CREATE PROCEDURE permission in the database and ALTER
permission on the schema in which the procedure is being created.
Therefore just giving CREATE PROCEDURE on it's own won't allow you to create a procedure. In fact, giving a ROLE the CREATE PROCEDURE permission, and not ALTER on the schema will result in the below error:
The specified schema name "dbo" either does not exist or you do not have permission to use it.
There is no ALTER PROCEDURE permissions, therefore, for a member of a ROLE to be able to both CREATE and ALTER a PROCEDURE you would need to do:
GRANT CREATE PROCEDURE TO YourRole;
GRANT ALTER ON SCHEMA::dbo TO YourRole; --Replace with appropriate schema name
This, however, will also enable to user to ALTER anyprocedures on said schema. Ut also enable those in the role to ALTER other objects on the schema as well (such as tables) though.
If your ROLE has permissions to ALTER the procedures and you want to remove that, you would need to run the below:
REVOKE ALTER ON SCHEMA::dbo TO YourRole;
This will, as mentioned, also revoke their ability to ALTER any other objects on said schema.
Remember, REVOKE doesn't DENY, it simply means that the USER won't inherited that permission from that ROLE any more. If the USER has the permission from a different ROLE, or they have the permission themselves, they will be able to continue to use the permission. If you must stop a USER from performing an action, regardless of any other permissions, they must have the DENY permission.
1) That can CREATE, ALTER and EXECUTE all stored procedures in
database
That's the db_owner role, or the CONTROL permission on the database. Anyone with all those permissions can escalate their own privileges to a database-level admin. So don't try.
2) That can only EXECUTE all stored procedures in database
GRANT EXECUTE TO [SomeRole]
3) That have no access to any stored procedures in database
A user has no access to any stored procedure unless you grant permissisions or add them to a role that has permissions.
I have to implement a financial application. One of the acceptance criteria is:
"The data may never change."
Therefore I need to prevent update and delete operations on the database, because it will be deployed on machines owned and administrated by the customer.
Is this even possible? Maybe with triggers? If not, are there any other databases that can prevent update and delete?
The easiest way is via roles, such as a query role. Grant select on the list of tables to that role, and grant that role to the user of your application. You can of course create others such as an admin role with update and delete privileges, to be granted later on when needed.
Example:
CREATE ROLE FIN_APP_INS_SEL_ROLE;
GRANT INSERT, SELECT on <table1> to FIN_APP_INS_SEL_ROLE;
GRANT INSERT, SELECT on <table2> to FIN_APP_INS_SEL_ROLE;
GRANT CONNECT, FIN_APP_INS_SEL_ROLE to <app_user>;
You can also make tablespaces read only,
ALTER TABLESPACE <name> READ ONLY;
or the entire database read only.
ALTER DATABASE OPEN READ ONLY;
It turns out to be impossible.
There is no way to grant an INSERT privilege without allowing to UPDATE. As I understand it, the INSERT privilege is interpreted as may alter data of that table.
I have created some stored procedures and I am trying to execute them within a web application. To endure the security I have created SQL Server users, logins roles and permissions.
Then I grant the execute permission to the rule and give that rule to a specific user. My problem is for example if I grant execution on StoredProcedureA to roleA and the StoredProcedureA uses a select on a tableA I got the error
SELECT permission was denied on the object '[tableA]'
The error is easy to fix: I have to grant select on that table.
But since I am using many procedure in my project, it's hard to make the modification for each one. Is there a way to configure SSMS so that If I grant the execute on a procedure to a role, that role will have automatically all the permission on the actions (select, insert, update, delete) that are in that procedure?
Thanks
Can you alter your procedure to include the EXECUTE AS clause?
Example:
ALTER PROCEDURE sprocName...
EXECUTE AS dbo -- high level example
...
This would allow you to only grant your users and roles the ability to execute the procedures but the procedures the ability to do what it needs to, be that select, insert, update, etc.
Is there a way I can give developers permission to grant a user permissions over objects without giving them the option to create users or functions?
I'm trying to limit developers permissions, I recently found out that developers had db_owner permissions in dev and prod environments! So I'm doing my best to stop this madness.
Any good article about this matter?
You can make them members of the "db_securityadmin" database role
As said, if someone could hand out permissions, they could hand out permissions to themselves (or a dummy account). I'm not sure if there is a trick in SQL Server to provide "give user permissions less then me".
The way I would do it is with stored procedures.
Create a stored procedure that gives a specified user a specific right or set of rights (those rights are the ones that regular users are allowed to have). Then give the developers execute access to this stored procedure. In effect you use stored procedures to create a limited version of GRANT, while keeping the full GRANT command to yourself.
If someone can give someone else permissions, he can also give himself the permission to do what he wants. So what is this good for? Probably I don't understand your situation.
Owners of objects can grant permissions on those objects. Provided your developers don't need to grant things like CREATE TABLE rights, you might be able to give them ownership of the objects that you want them to grant permission on.
As Stefan said, giving them grant permissions would effectively give them all permissions, since if they want to do something all they have to do is grant themselves the permissions to do it.
Rather than considering the developers the enemy, though, you may want to consider giving the developers a second user account that's used to administer the database. It's pretty common not to give developers ANY permissions to production, at least on their development account.
Setting permission on objects like stored procedures can be accomplished with "GRANT EXECUTE ON . to ;
However, you may also want to grant security rights at both the login and user level. You will want to determine and grant ONLY the necessary rights for the objects that require access (such as execution). Consider use of the "EXECUTE AS" capability which enables impersonation of another user to validate permissions that are required to execute the code WITHOUT having to grant all of the necessary rights to all of the underlying objects (e.g. tables). The EXECUTE AS can be added to stored procs, functions, triggers, etc.
Add to the code as follows right within the Stored Procedure: CREATE PROCEDURE dbo.MyProcedure WITH EXECUTE AS OWNER
In this case you are impersonating the owner of the module being called. You can also impersonate SELF, OR the user creating or altering the module OR... imperonate CALLER , which will enable to module to take on the permissionsof the current user, OR... impersonate OWNER, which will take on the permission of the owner of the procedure being called OR... impersonate 'user_name', which will impersonate a specific user OR... impersonate 'login_name' with will impersonate a specific login.
MOST of the time, you will only need to grant EXECUTE rights to stored procs and then rights are granted to all objects referenced within the stored proc.
In this way, you DO NO need to give implicit rights (example: to update data or call additional procs). Ownership chaining handles this for you. This is especially helpful for dynamic sql or if you need to create elevated security tasks such as CREATE TABLE. EXECUTE AS is a handy tool to consider for these.
This example may help clarify all of this:
Create a user called NoPrivUser with public access to a database (e.g. dbadb)
USE [master] GO CREATE LOGIN [NoPrivUser] WITH PASSWORD=N'ABC5%', DEFAULT_DATABASE=[dbadb], CHECK_EXPIRATION=ON, CHECK_POLICY=ON GO USE [DBAdb] GO CREATE USER [NoPrivUser] FOR LOGIN [NoPrivUser] GO
NOTE: CREATOR OR OWNER OF THIS PROCEDURE WILL REQUIRE CREATE TABLE RIGHTS within the target database.
use DBAdb go CREATE PROCEDURE dbo.MyProcedure WITH EXECUTE AS OWNER AS IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].MyTable') AND type in (N'U')) CREATE TABLE MyTable (PKid int, column1 char(10)) INSERT INTO MyTable VALUES (1,'ABCDEF')
GO
GRANT EXEC ON dbo.MyProcedure TO NoPrivUser; GO
-- Now log into your database server as NoPrivUser and run the following.
use dbadb go
EXEC dbo.MyProcedure
(1 row(s) affected)
Now try to select from the new table while logged on as NoPrivuser.
You will get the following:
select * from MyTable go
Msg 229, Level 14, State 5, Line 1 The SELECT permission was denied on the object 'MyTable', database 'DBAdb', schema 'dbo'.
That is expected since you only ran the procedure under the security context of Owner while logged on as NoPrivUser.
NoPrivUser as no rights to actually read the table. Just to execute the procedure which creates and inserts the rows.
With the EXECUTE AS clause the stored procedure is run under the context of the object owner. This code successfully creates dbo.MyTable and rows are inserted successfully. In this example, the user "NoPrivUser" has absolutey no granted rights to modify the table, or read or modify any of the data in this table.
It only takes on the rights needed to complete this specific task coded WITHIN the context of this procedure.
This method of creating stored procedures that can perform tasks that require elevated security rights without permanently assigning those rights come be very useful.
I've found that the most dangerous aspect of the db_owner role is that if you issue a deny on a permissions, then the members of the role can grant it back to themselves. I've just started reading about this and I'm testing this
Create role db_ControlDatabase
grant control to db_ControlDatabase
deny backup database to db_ControleDatabase
alter role db_ControlDatabase add member TestUser
So far, I've found that the subject TestUser has permissions without being able to add or remove members of the fixed database roles. You should be able to deny whatever you need at this point like backup certificate, backup master key, etc.
Here is a list of permissions that can be denied or granted: