I need your serious help here!
I need to run multiple grant execute query for sys object to one of my user.
grant execute on SYS.dbms_system to $(User);
grant execute on SYS.dbms_flashback to $(User);
But, as what I know, in order to grant privileges to sys object for Oracle RDS, we need use procedure rdsadmin.rdsadmin_util.grant_sys_object to achieve.
I construct my new query, as following:
begin
rdsadmin.rdsadmin_util.grant_sys_object('DBMS_SYSTEM', '$(User)');
end;
But, I hit an error,
SQL Error: ORA-20199: Error in rdsadmin_util.grant_sys_object.
ORA-20900: You do not have permission to grant: to SYS object: DBMS_SYSTEM ORA-06512: at "RDSADMIN.RDSADMIN_UTIL", line 234 ORA-20900:
You do not have permission to grant: to SYS object: DBMS_SYSTEM ORA-06512: at line 2
Anyone have clue how do I solve this? Please help!
Let's assume you have run the procedure correctly and you have included the execute privilege in the call. This error
ORA-20900: You do not have permission to grant: to SYS object: DBMS_SYSTEM
means you do not have sufficient permission to grant privileges on DBMS_SYSTEM. You may think you have that privilege but you don't.
Two possible explanations:
your granting user doesn't have its permission WITH GRANT OPTION and lacks the GRANT ANY PRIVILEGE power role.
your granting user gained its privileges through a role. We cannot use permissions granted through a role in PL/SQL, because of the Oracle security model. To do this permissions must be granted directly to the user.
"there is so many limitation within amazon RDS service ... it is such a huge disappointment from this service. "
It's the difference between IaaS and PaaS. The Amazon RDS offering is managed databases as a service. So it is quite reasonable for them to lock SYS, etc. SYS is for installing, configuring and patching the database, which are tasks undertaken by Amazon. (Many places use SYS for doing regular DBA tasks: they shouldn't.) If you want to do installing, configuring and patching for yourself then you need a different style of cloud service.
Related
I am working on a secure view and share in snowflake.
So, I need to grant reference_usage of each DB to share before granting view permission to share.
My view has like 7-8 databases in its statement(due to joining) and so I need to grant all these DB reference usage permission to share.
One way of doing this, I can run the below command for each database.
grant reference_usage on database db_XYZ to share share_ABC;
Is there any command in snowflake to grant permission to all databases at once?
No, the REFERENCE_USAGE privilege must be granted individually to each database.
https://docs.snowflake.com/en/sql-reference/sql/grant-privilege-share.html#usage-notes
Of course, you can write a script to generate and execute grant commands for all databases.
How exactly is the GRANT/REVOKE privileges affecting the database.
I have a solution ready for a problem where one of my components(an executable) is not identifying my oracle config packages. But is it possible for me to test by revoking with this,
revoke execute on package_name to user1;
And then again grant,
grant execute on package_name to user1;
In short, can this in anyway affect the privileges negatively. This is mainly because user1 is a generic user so that's why I am being cautious.
Thanks
But of course that revoking a privilege affects that user negatively ... it won't be able to use that package any more.
Things can be even more complicated if that user (user1) has granted privilege to other users (as it was granted privilege with grant option) because - once you revoke privileges from user1, Oracle will automatically revoke privileges from all those users/roles (that's what we'd call a cascading effect).
Therefore, be careful. I guess that your best option to test it is to have a separate - testing - database. There you can do anything you want, as it won't affect nobody in production.
Finally, it is revoke privilege FROM user, not TO (referring to the 1st statement you posted).
AWS created a procedure to grant permission on SYS objects in Oracle RDS which is "rdsadmin.rdsadmin_util.grant_sys_object()" as an alternative for using the GRANT command.
Any idea how to revoke such permission after granting it.
I tried to use the default REVOKE command but it raised error similar to the one when trying to use GRANT instead of "rdsadmin.rdsadmin_util.grant_sys_object()".
Also, i did not find any procedure in AWS Oracle RDS similar to the grant one that can revoke, e.g.:
"rdsadmin.rdsadmin_util.revoke_sys_object()"
Thanks.
These two privileges don't get granted to the DBA:
SYSDBA
SYSOPER
SQL and GUI attempts to grant these privileges return successful messages, but they remain revoked. While signed in as SYS:
Signing in as SYS
Bookshop_DBA privileges appear as such
Granting with GUI
Granting with SQL
Result for both
Messages are returned to say that granting is successful but no changes are made.
Please show us what you're actually doing.
If you're using the dialog as shown, and getting problems, you should be able to report an any ORA- errors.
For example:
And you don't have to guess what SQL Developer is actually doing - click on the SQL page of the edit user dialog.
Before going further, please consider:
you should in general NEVER login as SYSDBA - unless you need to actually shut down or alter a database. Don't use it as an all powerful PRIV to get around security/grant issues
you should know what you're doing before you grant it to someone, or even use it yourself. Read the docs, then read them again. Otherwise, this is how you do very, very bad things to your database.
Running this code from a non-privileged user:
-- SYSTEM PRIVILEGES
GRANT SYSDBA TO "user" ;
GRANT SYSOPER TO "user" ;
Error starting at line : 6 in command -
GRANT SYSDBA TO "user"
Error report -
ORA-01031: insufficient privileges
01031. 00000 - "insufficient privileges"
*Cause: An attempt was made to perform a database operation without
the necessary privileges.
*Action: Ask your database administrator or designated security
administrator to grant you the necessary privileges
Error starting at line : 7 in command -
GRANT SYSOPER TO "user"
Error report -
ORA-01031: insufficient privileges
01031. 00000 - "insufficient privileges"
*Cause: An attempt was made to perform a database operation without
the necessary privileges.
*Action: Ask your database administrator or designated security
administrator to grant you the necessary privileges
So, how do we get around this?
You need to do this for the user who is performing the grants - and you better REALLY trust this user, if you're going to let them do this SYSDBA...
GRANT SYSDBA TO "*user*" WITH ADMIN OPTION;
But, that's NOT ENOUGH.
Per the DOCS:
Because SYSDBA and SYSOPER are the most powerful database privileges,
the WITH ADMIN OPTION is not used in the GRANT statement. That is, the
grantee cannot in turn grant the SYSDBA or SYSOPER privilege to
another user. Only a user currently connected as SYSDBA can grant or
revoke another user's SYSDBA or SYSOPER system privileges. These
privileges cannot be granted to roles, because roles are available
only after database startup. Do not confuse the SYSDBA and SYSOPER
database privileges with operating system roles.
So, in SQL Developer, disconnect.
Change your connection properties:
Now that you're connected as SYSDBA, you can do...perilous things...like grant that to someone else.
PS - Don't ever GRANT SYS anything to a demo schema like HR. And don't have these demo schemas in production environments, they're only there as learning resources.
It may be due to the user you are connected with. SYSDBA and SYSOPER privs can only be granted by a SYSDBA user.
I need to use dbms_lock.sleep procedure from user usr1. I can't login as sys, but I have a password for user usr2 which have "grant any object privilege" privilege. However, when I'm logged in as usr2 and try to issue
grant execute on sys.dbms_lock to usr1
I get the ORA-01031 "insufficient privileges" exception. The same works with a test package on another user. Are the system packages treated specially, or have I missed something?
The system packages are treated specially, depending on the value of the initialisation parameter O7_DICTIONARY_ACCESSIBILITY. If that is FALSE, which is the default since Oracle 9i, then ANY privileges don't apply to the data dictionary. The documentation refers to this as 'dictionary protection'.
The closest I can find in the security guide - here and here - only refer to tables as examples.
Oracle Support note 174753.1, however, explicitly states that dictionary protection supersedes grant any object privilege. I'm not allowed to quote that but it explains what you're seeing; it might be worth looking up if you have access to it.
So, the only way for usr2 to be able to grant execute on sys.dbms_lock to usr1 is for the DBA to have done grant execute on sys.dbms_lock to usr2 with grant option.
As Ben says, you'll have to either get the DBA to grant the permission to usr1 directly, or add the with grant option to the privileges granted to usr2; or have usr2 create a wrapper procedure around the dbms_lock call and grant permissions on that to usr1.
It sounds as though SYS hasn't been granted the DBA role or that SYS doesn't have the GRANT ANY OBJECT privilege. To quote from the documentation
To grant an object privilege, you must own the object, or the owner of
the object must have granted you the object privileges with the GRANT
OPTION, or you must have been granted the GRANT ANY OBJECT PRIVILEGE
system privilege. If you have the GRANT ANY OBJECT PRIVILEGE, then you
can grant the object privilege only if the object owner could have
granted the same object privilege.
This implies that you can't grant execute on dbms_lock because SYS wouldn't have been able to do so.
On installation SYS is automatically granted the DBA role so maybe someone's been changing this or created another user with the DBA role.
Either way you're going to have to get your DBA involved if you only have access to these two users. Ask them to grant execute on the packages you need to the users that need it. It's up to them to give you a good reason why they won't grant you execute on the packages you need in order to do your job.
If you can't get full access to dbms_lock you can always create a procedure in another user that wraps dbms_lock.sleep you need and then grant execute on that procedure alone.