Bug 45040

GemStone/S 64 Bit

3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2, 3.1.0.6, 3.1.0.5, 3.1.0.4, 3.1.0.3, 3.1.0.2, 3.1.0.1, 3.1, 3.0.1, 3.0, 2.4.8, 2.4.7, 2.4.6, 2.4.5.3, 2.4.5.2, 2.4.5.1, 2.4.5, 2.4.4.8, 2.4.4.7, 2.4.4.6, 2.4.4.5, 2.4.4.4, 2.4.4.3, 2.4.4.2, 2.4.x, 2.4

All Platforms

3.2.5

Read authorization checks happen when object faulted into memory

In GS/S 32-bit, read authorization checks were made when an object was actually accessed, such as reading an instvar or element, or checking some attribute of the object, such as its size or class.  With the re-introduction of object security in GS/64 2.0, read authorization checks now occur when an object is faulted into the VM memory.  This can cause 2115 #authErrSegRead read authorization errors (SecurityError) to be generated earlier in code execution than in GS/S 32-bit.   This can in turn cause exception handlers to not be triggered properly because they do not cover the point of object faulting.

Workaround

Refactor 2115 #authErrSegRead (SecurityError) exception handlers to cover the new location of error triggering.


Last updated: 3/9/15