I need to grant object privileges to a user but I'm not the owner of the schema.
I've tried doing it with the System user but I can't either.
My long shot was using the Sys user (other than System) but it is deactivated and there is no way I'll be able to activate it with my user.
Is there any way I grant that privilege to a user? I can't ask the owner of the schema to do that because she resigned today... and I don't wanna change the pwd of her DB user.
I know that at some point I'll need to create a new DBAdmin user and create a backup of those schemas because when the SAP user of my colleague be deleted, it'll delete the Hana user and the DB user with all of the objects, roles and privileges created and granted with it.
Oh oh!
Be very careful here with the deletion of the user since - as you correctly write - the deletion will have a cascading effect.
Also:
you have to either have the ownership for the objects OR the privileges you want to grant with grant option.
Using the SYSTEM user won't help with that and SYS can never be used to logon to the database anyway.
Since there is also no way to take over ownership, the only actual way really is to find out which objects and privilege grants the user has created/performed.
Then logon to the user and refactor the grants to roles that cover the object privileges.
As a next step, you may consider creating a non-logon user to own the objects and then perform a import/export of the users' objects.
Finally you may create design time roles with the required privileges to the objects. This allows granting/revoking of the privileges by a user with the ROLE ADMIN privilege, which makes management a lot easier and better structured.
Sure:
(
SELECT "SCHEMA_NAME",
'' AS "OBJECT_NAME",
'SCHEMA' AS "OBJECT_TYPE", "SCHEMA_OWNER" as "OWNER_NAME"
FROM "PUBLIC"."SCHEMAS"
WHERE SCHEMA_OWNER = 'A' UNION ALL
SELECT "SCHEMA_NAME", "OBJECT_NAME",
"OBJECT_TYPE", "OWNER_NAME" FROM "PUBLIC"."OWNERSHIP"
WHERE
"SCHEMA_NAME" IN
( SELECT "SCHEMA_NAME" from "PUBLIC"."SCHEMAS"
WHERE "SCHEMA_OWNER" = 'A' ) OR "OWNER_NAME" = 'A'
) ORDER BY "SCHEMA_NAME" ASC, "OBJECT_NAME" ASC;
You find this and lots of other useful stuff in the SAP HANA book I wrote: https://www.sap-press.com/sap-hana-administration_3506/
Related
Can we grant direct select or insert access( with out creating a role ) to a user on a table ?
No, you cannot. Snowflake uses Role-based Access Control (RBAC):
https://docs.snowflake.com/en/user-guide/security-access-control-overview.html#access-control-framework
Therefore, all access on a table should be granted through a role.
https://docs.snowflake.com/en/sql-reference/ddl-user-security.html#access-control-management
Of course you can use "existing roles" instead of "creating a new one".
The short answer is NO - you can only grant access to a ROLE - never directly to a USER.
In Snowflake, everything is accessed via a ROLE. See this diagram:
RBAC: USERS, ROLES and SECURABLE OBJECTS
From this article: https://www.analytics.today/blog/introducing-snowflake-rbac
In summary:
USERS are granted one or more ROLES
A ROLE is granted PRIVILEGES (for example, insert, update, delete) on SECURABLE OBJECTS (for example a TABLE or VIEW)
Even the concept of OWNERSHIP is different in Snowflake. Every USER with the same ROLE shares access to the OBJECTS. This has some unusual results.
For example:
If a USER creates a TABLE - everyone with the same ROLE has OWNERSHIP on the table.
You can read more about Snowflake RBAC on this article - which also links to another two which explain best practices on how to deploy. https://www.analytics.today/blog/introducing-snowflake-rbac
I am working on the application which works on Oracle. For some kind of logic I need to get the list of tables from the given db user with the specified schema. In my case, I have a user which have granted access of the given schema. So when my code creates connection using the given credential and tries to fetch the tables from the following query, its return table list.
SELECT * FROM dba_objects where owner ='schema' and object_type = 'TABLE'
The above query was working with user having grant all privileges
but when I did try with limited permission, it is throwing error msg.
ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
For the secondary user, from which our code is creating connection has granted permissions by following query
create user johnsmith identified by Passw0rd;;
grant connect to johnsmith ;
grant select any table to johnsmith ;
grant UPDATE any table to johnsmith ;
grant DELETE any table to johnsmith ;
grant INSERT any table to johnsmith ;
Which permission should I grant to user to have access on the following system tables...?
dba_objects
user_constraints
user_cons_columns
USER_TABLES
all_tab_cols
and also allow to access dbms_metadata.get_dependent_ddl() method
With the O7_DICTIONARY_ACCESSIBILITY initialisation parameter set to false, which is the default, then:
System privileges that provide access to objects in other schemas do not give other users access to objects in the SYS schema. For example, the SELECT ANY TABLE privilege allows users to access views and tables in other schemas, but does not enable them to select dictionary objects (base tables of dynamic performance views, regular views, packages, and synonyms). You can, however, grant these users explicit object privileges to access objects in the SYS schema.
So you can either grant select privileges on the specific views you need:
grant select on sys.dba_objects to johnsmith;
and the same for other views; or if you need them to have wider access to the SYS schema objects you can give them that with a role:
grant select_catalog_role to johnsmith;
though the principle of least privilege should always apply, so this may be overkill and potentially expose things you don't want that user to be able to see.
You don't need to grant anything for the user to be able to query user_* views. If you meant the DBA equivalents of those - e.g. dba_tables - then grant them as for dba_objects above; or they woudl be included in select_catalog_role. But again, only grant what is actually needed.
Either way, for dbms_metadata you can just grant privileges on that package too (you can't grant privileges on individual procedures in a package):
grant execute on dbms_metadata to johnsmith;
or - again probably much more than actually needed, and potentially much more dangerous that the select role:
grant execute_catalog_role to johnsmith
How do I replace the ALL permission now that it has been revoked:
REVOKE ALL ON dbo.MyObject TO MyUser
I'm looping through all the objects in a database and revoking all permissions for a specific user. So if I had to be specific about which permission to revoke, it would be a real hassle because I would have to find out what object I have and then revoke every possible permission for that type of object. Instead of just REVOKE ALL.
You can't revoke all on schema::dbo to your user but you can...
REVOKE select,update,delete,insert,execute,references on schema::DBO to USER
If you want to get a list of securables to which a database principal has been granted permission, look no further than sys.database_permissions. How to interpret the major_id and minor_id columns depends on the value of the class column (for instance, if class = 1, then major_id = object_id and minor_id = column_id). I leave that as an exercise to the reader (check out the BOL entry for it here: http://msdn.microsoft.com/en-us/library/ms187719.aspx).
Another option might be just to drop and re-add the principal. Dropping the principal would get rid of any permissions associated directly to it and re-adding it doesn't grant any (unless you specifically grant some). That might be another option (but test it first!).
You really need to have some idea what permissions you want the user to have. the pattern you have there is "Just revoke everything, then later put back whatever was there before...".
If you really need to do that, then you will have to keep your own record of what the permissions were to begin with.
A better solution would be to have some idea what the permissions ought to be. Who knows? They may have been wrong before!
Does newly created user:
create user John
identified by secret;
have some privileges? Or is there any oracle config for privileges of newly created user? I need information about this topic.
Nope, no privileges.
select * from dba_sys_privs where grantee='JOHN';
select * from dba_tab_privs where grantee='JOHN';
select * from dba_role_privs where grantee='JOHN';
ammoQ is technically correct.
Given the user created as above does not have CREATE SESSION privilege, it cannot actually log on yet, or do anything else.
It is possible for another user with an appropriate CREATE ANY ... privilege to create objects (such as procedures, functions, triggers) under JOHN's schema/user. If so, then JOHN would automatically have privileges to drop those objects (but without a CREATE SESSION privilege, it would be difficult for them to achieve that).
From a security point of view, Oracle does have a bunch of privileges granted to PUBLIC. Once a user is created they do have a bunch of things they can do (eg select from views such as ALL_USERS).
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: