New Parameters in Oracle Database 184.108.40.206 with July 2016 PSU/BP
By following an internal discussion and checking parameter changes between Patch Set Updates (PSU) and Proactive Bundle Patches (BP) I learned that we introduced two new SPFILE parameters in Oracle Database 220.127.116.11 with the July PSU and BP. One is documented in the patch readme, the other one can be found right now only in the Oracle Database 18.104.22.168 manual:
The Oracle 12.2 documentation about ALLOW_GROUP_ACCESS_TO_SGA, the parameter which appears not in the Oracle 12.1 documentation right now, says:
groupaccess to shared memory on UNIX platforms.
The default value is FALSE, which means that database shared memory is created with
owneraccess only. In Oracle Database releases prior to Oracle Database 12c Release 2 (22.214.171.124), database shared memory was created with
When this parameter is set to TRUE, database shared memory is created with
groupaccess. This behavior grants permissions to DBAs to manage shared memory outside the database, but also allows DBAs to read and write to shared memory, which may not be desirable for certain installations.
So there’s a tiny correction required:
It should say “prior to Oracle Database 126.96.36.199 July 2016 PSU/BP”.
188.8.131.52.DBBP:160719 21281607E Transparently encrypt tablespace at creation in Cloud (adds “encrypt_new_tablespaces”)
Why does ALLOW_GROUP_ACCESS_TO_SGA appear in Oracle Database 184.108.40.206?
Simple reasons: it will make Oracle Database 220.127.116.11 more secure. Default for this parameter is FALSE – which actually changes behavior but may not affect you at first sight. And that’s why I blog about it.
You will recognize that the Oracle executable runs now with permission “600” – whereas it was “640” before. See my example of an 18.104.22.168 database with the January 2017 BP in place:
$ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 23298063 oracle 600 2932736 76 0x00000000 23330832 oracle 600 1040187392 38 0x00000000 23363601 oracle 600 5455872 38 0xc8969114 23396370 oracle 600 20480 38 ...
whereas my 22.214.171.124 database runs with different permissions:
$ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 22872084 oracle 640 12582912 21 0x00000000 22904853 oracle 640 721420288 21 0xd41b1c5c 22937622 oracle 640 2097152 21 ...
Does this effect the connection of your applications to the database?
No, of course not.
It has only an effect if you try to access the SGA from the OS level, i.e. attaching to the shared memory segment. In the old behavior an OS user being in the same group can attach and read from the SGA. With the new “600” protection only the OWNER can attach to it – and read out the SGA.
This is the standard behavior in Oracle Database 126.96.36.199 and onward. And it has been backported to the July 2016 PSU and Proactive Bundle Patches which are cumulative, i.e it is in all following PSUs and BPs included as well.