Learn the Oracle Database 12c Inherit Privileges Privilege. Demonstration and Examples.
There's a whole new privilege. The inherit privileges privilege. We indeed inherit any privileges privileged. That's just in privileged of course. Any privileges - system privileges, any privileges is an object privilege or new type objects. We can now assign privileges, grant privileges on users.
It limits the owner's inheritance of privileges from the invoker. Oracle Corporation is presumably reasonably happy with the way definer's rights code works and definer's rights code as I demonstrated can be highly dangerous.
That hasn't really changed in the current release except is will see with the ability to grant roles to code because in invoker's rights we've got huge differences and that's the inheriting of privileges privilege. If you don't have the inheritance enabled, any attempt to execute invoker's rights code will fail because the definer will not be in able to inherit the rights of the invoker.
So I'm going to go straight in to do it and then go through the rest of the slides so we can see the sort of issue. Let me lose 11g and go to 12c. What I shall do is create my low privileged user or drop user dev. I don't think he exists. He doesn't. So I'll create my low privileged user.
Grant create session, create procedure, select any table to dev identified by dev. It's the same mechanism I use. The same command I use in 11g. I'm creating a developer with a bare minimum that he needs to do his job, which is writing code that lets people query the database.
Then log on as him, comm dev/dev and create my procedure. I'll create a version of the code, create or replace procedure list_emp, author ID current user. Invoker's rights code. Remember, this gives my low privilege user dev the ability to insert something horrible in his code which shall then be executed with the invoker's rights.
We create the procedure.
Now connect / as sysdba - I'll be the highest possible person there is - set server output on and run the code.
Execute dev.list_emp looking for the CLARKS. I can't do it. Even as user sys, I can't run that because of the lack of this new privilege. I can correct the situation. I can grant inherit privileges on user sys - which of course one would never normally do - to dev. So I'm now giving my low privilege user the ability to inherit the privileges of user sys when we are running invoker's rights code. And having done that, the code now succeeds.
That's the general principle. Without this inherit any privileges code all that doesn't have any privileges privilege, all your invoker's rights code is now blocked. It simply won't run until you grant that privilege to your trusted user.
So without inheritance the invoker's rights code will fail. This privilege is in fact granted by default in 12.1 when a user is created. I believe this is purely for backward compatibility. So you don't have to worry about all your codes ceasing to function the moment you have to upgrade but there's no guarantee that this situation will remain as we go through 12.2, 12.3.
Also in upgrade I haven't had the time to test comprehensively every possible method of upgrade but certainly this simple test I've done so far, the privilege does appear to be being granted and we can see it.
If we look at who's been granted this privilege so far
Select grantee, table_name, privilege from dba_tab_privs where privilege like inherit and we see that straight out of the box inherit privileges on a number of users have been granted to public. They have been granted to public. So if I create a brand new user, I grant connect to jw identified by jw, we will see that in the current release - there he is - inherit has beeen granted to public.
In the current release by default, your code will continue to function and Oracle often does this with their [05:46 inaudible] with powerful new features. By default, it's configured so there's no change and in the next release it all changes. That's happened to a quite a few releases, quite a few new features, and it wouldn't surprise me if by the time we get to say 12.2 and certainly by the time we get to 13 this behavior changes.
So plan for it and look at that privilege and see who it's been granted to and secure your systems. What you need to do is revoke all the inherit privileges grants that's there by default and then grant inherit any privileges very, very sparingly only to a very few trusted users and that should tighten up the danger of definer's inheriting invoker's rights. So a few trusted schemas, create the code in those schemas only and control this very tightly indeed.
There's a whole new privilege. The inherit privileges privilege. We indeed inherit any privileges privileged. That's just in privileged of course. Any privileges - system privileges, any privileges is an object privilege or new type objects. We can now assign privileges, grant privileges on users.
It limits the owner's inheritance of privileges from the invoker. Oracle Corporation is presumably reasonably happy with the way definer's rights code works and definer's rights code as I demonstrated can be highly dangerous.
That hasn't really changed in the current release except is will see with the ability to grant roles to code because in invoker's rights we've got huge differences and that's the inheriting of privileges privilege. If you don't have the inheritance enabled, any attempt to execute invoker's rights code will fail because the definer will not be in able to inherit the rights of the invoker.
So I'm going to go straight in to do it and then go through the rest of the slides so we can see the sort of issue. Let me lose 11g and go to 12c. What I shall do is create my low privileged user or drop user dev. I don't think he exists. He doesn't. So I'll create my low privileged user.
Grant create session, create procedure, select any table to dev identified by dev. It's the same mechanism I use. The same command I use in 11g. I'm creating a developer with a bare minimum that he needs to do his job, which is writing code that lets people query the database.
Then log on as him, comm dev/dev and create my procedure. I'll create a version of the code, create or replace procedure list_emp, author ID current user. Invoker's rights code. Remember, this gives my low privilege user dev the ability to insert something horrible in his code which shall then be executed with the invoker's rights.
We create the procedure.
Now connect / as sysdba - I'll be the highest possible person there is - set server output on and run the code.
Execute dev.list_emp looking for the CLARKS. I can't do it. Even as user sys, I can't run that because of the lack of this new privilege. I can correct the situation. I can grant inherit privileges on user sys - which of course one would never normally do - to dev. So I'm now giving my low privilege user the ability to inherit the privileges of user sys when we are running invoker's rights code. And having done that, the code now succeeds.
That's the general principle. Without this inherit any privileges code all that doesn't have any privileges privilege, all your invoker's rights code is now blocked. It simply won't run until you grant that privilege to your trusted user.
So without inheritance the invoker's rights code will fail. This privilege is in fact granted by default in 12.1 when a user is created. I believe this is purely for backward compatibility. So you don't have to worry about all your codes ceasing to function the moment you have to upgrade but there's no guarantee that this situation will remain as we go through 12.2, 12.3.
Also in upgrade I haven't had the time to test comprehensively every possible method of upgrade but certainly this simple test I've done so far, the privilege does appear to be being granted and we can see it.
If we look at who's been granted this privilege so far
Select grantee, table_name, privilege from dba_tab_privs where privilege like inherit and we see that straight out of the box inherit privileges on a number of users have been granted to public. They have been granted to public. So if I create a brand new user, I grant connect to jw identified by jw, we will see that in the current release - there he is - inherit has beeen granted to public.
In the current release by default, your code will continue to function and Oracle often does this with their [05:46 inaudible] with powerful new features. By default, it's configured so there's no change and in the next release it all changes. That's happened to a quite a few releases, quite a few new features, and it wouldn't surprise me if by the time we get to say 12.2 and certainly by the time we get to 13 this behavior changes.
So plan for it and look at that privilege and see who it's been granted to and secure your systems. What you need to do is revoke all the inherit privileges grants that's there by default and then grant inherit any privileges very, very sparingly only to a very few trusted users and that should tighten up the danger of definer's inheriting invoker's rights. So a few trusted schemas, create the code in those schemas only and control this very tightly indeed.
- Category
- Success
Sign in or sign up to post comments.
Be the first to comment