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).
Related
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 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.
Whenever I give a user "all privileges" in ORACLE (example below), what does this actually do?
My understanding is that it gives a user any privilege, e.g inserting, deleting etc within that schema but not to any schema in the DB?
grant all privileges to my_user;
You can grant all [privileges] on <some object>, but you aren't specifying an object; so you are granting system privileges:
The documentation for system privileges says:
Oracle Database provides the ALL PRIVILEGES shortcut for granting all the system privileges listed in Table 18-1, except the SELECT ANY DICTIONARY, ALTER DATABASE LINK, and ALTER PUBLIC DATABASE LINK privileges.
System privileges are not always restricted to a schema. That table includes a lot of ANY privileges, which are specifically not restricted to a schema. If you grant all privileges to a user they will be able to create or alter a table in any schema, for example. That probably isn't what you want.
There is no shortcut to grant only schema-restricted privileges. You'll need to grant CREATE TABLE, CREATE INDEX, etc. explicitly.
It's common practice to create a role to which you grant the necessary privileges, and then you just have to grant that role to your users. (Although you sometimes still need to grant privileges directly to users, e.g. if they are required in a stored procedure).
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.
I have to install an application server that requires an user to write to the database, possibly create new schemes and such. However, I've always used the "work around" to assign the DBA Role to that user.
I have some questions, as I am not that deep into Oracle security.
Has the DBA role a level of privileges that can affect the whole Oracle installation?
Where can I find what privileges the DBA role exactly have?
How do I create an alternative role?
Thanks,
1) Yes, the dba role should have enough privileges to screw up a database beyond fixing.
2)
select *
from role_sys_privs
where grantee = 'DBA';
3) Unless you plan on having several user with similar privileges, I recommend creating a user and grant all needed privileges explicitly to this user instead of via a role.
You can read more about the topic in
Oracle Database Security Guide chapter 11, Administering User Privileges, Roles, and Profiles
First look into Ronnis' solution. If this is not sufficient create a package, owned by SYSTEM, and grant EXECUTE to the user or users that need it. Add procedures that perform the needed operations taking care to limit their power as much as possible.