On 6/25/2014 9:02 PM, Xiaomin Ding wrote:
On 6/16/2014 10:40 PM, David M. Lloyd wrote:
On 06/16/2014 09:19 AM, Frank Ding wrote:
Hi Jeff,
Thanks for your reply. One further question is that you confirmed
that two AccessControlContext objects considered equal via method
equals() should return same results for
AccessControlContext.checkPermission() but test shows that 2
AccessControlContext objects are equal regardless of isLimited,
limitedContext, parent, permissions, or privilegedContext. Does it make
sense and apply to Java 8 AccessControlContext with JEP140?
Is it not true that a limited privileged context simply adds a
protection domain that restricts permissions to the limited set? This
seems to be the "obvious" implementation of the feature.
If so, then equals() should have taken it into account as a matter of
course.
--
- DML
Hi Jeff,
Could you pls let us know your insight?
JDK 8 introduced, via JEP 140, some new variants of the doPrivileged()
method. The older
doPrivileged() methods simply stop the access control algorithm during a
security check
so that earlier method's ProtectionDomains on the call stack (or
inherited from the parent
thread etc.) are not considered and will not cause a security check to
be denied.
The new "limited" variants from JEP 140 take one or more Permission
instances as
parameters that describe which specific permission checks should stop
the stack walk.
Other security checks that do not match the new Permission parameters
will cause the
stack walk to continue as if the doPrivileged() method had not been
used. This allows code
to use doPrivileged() to assert a limited subset of its own permissions
without asserting all
of them.
As Frank noted, an AccessControlContext instance may have some
additional internal fields
initialized when it is created within the scope of a limited version of
the doPrivileged() method.
These fields are checked in JDK 8 as part of the equals() and
checkPermission() implementations.
Read the full class-level documentation carefully at the top of the
javadoc page
for java.security.AccessController. It describes the call stack walking
algorithm
used during a security check and how that works with the new JDK 8
limited doPrivileged() methods
that were added by JEP 140.
Here are some javadoc links:
http://docs.oracle.com/javase/8/docs/api/java/security/AccessController.html
http://docs.oracle.com/javase/8/docs/api/java/security/AccessController.html#getContext--
http://docs.oracle.com/javase/8/docs/api/java/security/AccessController.html#doPrivileged-java.security.PrivilegedAction-java.security.AccessControlContext-java.security.Permission...-
For additional background on the new JDK 8 feature that allows limiting
the access provided by
the use of doPrivileged() please see the following technote subsection:
http://docs.oracle.com/javase/8/docs/technotes/guides/security/doprivileged.html#asserting_a_subset_of_privileges
And this is the original feature request:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7083329
Two AccessControlContext instances can be created or obtained under
differing circumstances
and still be considered equal() if they would always check the same
internal ProtectionDomains
during a call to checkPermission(). AccessControlContexts created within
the influence of one
of the new JEP 140 methods add some complexity.
For instance, if you call AccessController.getContext() when there is a
JDK 8 "limited" version of the
doPrivileged() method on the thread's call stack it will return an
AccessControlContext that conceptually
captures and encapsulates the ProtectionDomains of the methods on the
call stack leading back
to the doPrivileged() call and it will also include the limiting
permission parameters of that
doPrivileged() call and the earlier call stack elements above the
doPrivileged() call. This allows
a later direct call to the AccessControlContext's checkPermission()
method on any thread
to behave the same as a call to AccessController.checkPermission() on
the original thread.
You might think that this "fancy" AccessControlContext containing the
limited doPrivileged() state
could not be equal to a "simple" AccessControlContext captured by
AccessController.getContext()
on a thread without any doPrivileged() method on the call stack or with
a non-limited doPrivileged()
method on the call stack. However, this may not be true. If the
ProtectionDomains on the call stack
leading back to the doPrivileged() method are a superset of the
ProtectionDomains that are reachable
beyond the limited doPrivileged() then those later ProtectionDomains are
redundant and the conceptually
"fancy" instance will have actually been created with the same internal
state as the "simple" instance.
