On 09/09/2013 04:56 PM, Mandy Chung wrote:
On 9/9/13 10:01 AM, David M. Lloyd wrote:
I'm not sure if we can be very certain about the depth in a runtime
environment (non-debugging) unless it requires all VM implementation to
support a reliable way to return a frame at a given depth.
The stack trace is not guaranteed to contain all stack frames. E.g. in
the spec of Throwable.getStackTrace():
Some virtual machines may, under some circumstances, omit one or
more
stack frames from the stack trace. In the extreme case, a virtual
machine
that has no stack trace information concerning this throwable is
permitted to return a zero-length array from this method.
This is interesting. Presumably this would tie into tail-call
optimizations and that sort of thing?
How does AccessControlContext deal with this possibility?
Will need the VM team to answer the details.
ACC only needs protection domains that allow the VM to do some ACC
optimization, for example, the comment in JVM_GetStackAccessControlContext
// count the protection domains on the execution stack. We collapse
// duplicate consecutive protection domains into a single one, as
// well as stopping when we hit a privileged frame.
Also classes on bootclasspath have null protection domain in the VM
itself that it can bypass permission check on those frames.
Leaving the bootclasspath stuff aside, it would be very useful for (at
least) security managers to be able to acquire *just* their immediate
caller's ProtectionDomain without having to worry about spoofing or
anything like that. This would definitely solve my security manager use
case at the very least - it would allow writing privileged versions of
methods which would not require a slow doPrivileged() call; instead I
could just check against the immediate caller's permission set.
--
- DML
