I am learning oracle and PL/SQL. I have created a database called "PRACTICE" and created a user called "MITHRA" by connecting as a SYS.
My question is i want to grant privileges to the user "MITHRA" for the specific database "PRACTICE". The user "MITHRA" can able to do all activities like create, drop, alter etc.. only in "PRACTICE" database.
Please suggest me how to do this.
Oracle can only host one database so what you are asking for will essentially grant root privileges to this user, including drop database. This should be avoided on production from obvious reasons.
So in order to grant full access to user mithra:
Connect as sys and run the following command -
Grant dba to mithra;
That should give the user mithra all possible privileges for that database.
You can also use the grant command the grant any distinct privileges.
Just to be sure that we speak in the same terms.
Is the "PRACTICE" database or schema? If it is DATABASE then you should grant DBA, if it is schema then Oracle does not have statements to grant rights to schemas (only system and object priveleges). Reading your question makes me think that you come from MSSQL where you can grant to a specific user gratns to specific database, in Oracle it is a little bit different - to make an analogy - you do not have databases but schemas.
Related
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
I have been granted db_datareader access to our production SQL Server database, but they also granted me the denywrite permission, as a safety precaution to make sure I absolutely cannot break our services during the course of my investigations.
However, I am finding that I cannot see our stored procedures - the list appears empty.
We should have hundreds of stored procedures in our production environment, so I'm perplexed as to why they aren't showing up in the object explorer.
Our infrastructure manager granted me the rights, but he doesn't know anything about SQL Server, so management has asked me to assist with figuring out which SQL Server permissions I need, since I am the developer.
So I need to know what I'm missing here - I assumed db_datareader would let me view everything, including stored procedures and metadata, but apparently I was mistaken. :)
Admittedly, I'm not the most knowledgeable when it comes to permissions. However, I believe the minimum permission you need here is view definition. You can also grant this permission to a role if it makes more sense for your situation.
use MyDB
GO
GRANT VIEW DEFINITION to MyUser
The above will grant view_definition to MyUser for the MyDB database.
Changing to the following will grant view definition on any database:
use master
GO
GRANT VIEW ANY DEFINITION to MyUser
Sources:
https://msdn.microsoft.com/en-us/library/ms345443.aspx#Security
http://www.mssqltips.com/sqlservertip/1593/granting-view-definition-permission-to-a-user-or-role-in-sql-server/
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.
What is the best way to prevent changes to a database or verify the integrity of this, so that it can not be altered from an application created for this database.
assuming you have a username and password to access the database permits reading - writing.
requirements:
The user has write permissions
Do not depend on a particular system like (MySQL, Oracle, SQL Server)
solution I'm looking for is not based on the user's permissions on the database
Most modern databases allow you to grant reading and writing permissions but while disallowing DDL commands like ALTER TABLE.
Do not give users that should not alter the DB structure permission to execute DDL.
If by "Alter" you mean change any data rows, rather than the database structure, you can grant the user only SELECT rights.
The user or account that your application uses must be granted permissions from the database server. Typically permissions include things like:
Select
Insert
Update
Delete
Alter
Drop
Only give the user account the permissions needed; in other words, don't grant Alter permission, and the application (or anyone using the same login) won't be able to alter tables.
Two strategies: 1) if you are running SQL Server, Oracle, DB2, etc, you can configure permissions so users are reader/writer by default (which means no alter permissions). 2) you can periodically check to see if someone has changed the data structure or even set up a DB trigger to detect changes and record who/when, etc (depends on your DB platform)
What Server Role(s) and/or Database Role(s) must a SQL Login have to do the following:
Read Data (including Temp tables)
Write Data (including Temp tables)
Execute any SP within a database which they are granted access
We are migrating from SQL 2000 to 2008 and I'm going through all the Logins and have noticed they are all set to sysadmin & db_owner, which isn't good. Our apps that use these logins will only do what I've listed above so that's why I'm wondering. I know I can set each Login with a Database Role of db_datareader & db_datawriter but that doesn't include executing SP's. We've got close to 300 SP's in 2 or our DB's and to have to go through each SP and set the login permissions in the Extended Properties would be WAY too long and tedious.
Any help is greatly appreciated!
to have to go through each SP and set the login permissions in the Extended Properties would be WAY too long and tedious
And yet, this would also be the most secure.
Using the built in roles exposes too much of your database to your application.
Can you give the db_datareader and/or db_datawriter execute rights? This will give the user rights to execute any stored procedures in databases it has access to. If you have views you will also need to grant them select rights.
GRANT EXECUTE TO db_datawriter
I would either just deal with it and set the permissions manually or (my preference) create database roles that have the types of permissions you want to give, and assign logins to those. That way if multiple logins need the same set of permissions, you just give them the same role.
As a bonus, if your programmability objects have some sort of prefix naming convention so that (for example) procedures that read from your login information tables all start with something like pAccount_ or something, then you can dynamically do GRANTs to roles based on the prefix of the routine.