[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug classpath/44007] New: Bad execution and assigned contexts combinati

From: pierre dot mobde at gmail dot com
Subject: [Bug classpath/44007] New: Bad execution and assigned contexts combination in VMAccessController.getContext
Date: 6 May 2010 08:56:35 -0000

In VMAccessController.getContext, the executing context and the assigned one
should be united, not intersected.

I think that this code's author might have misunderstood the
ActionController.doPrivileged method documentation which says:

Performs the specified PrivilegedExceptionAction with privileges enabled and
restricted by the specified AccessControlContext. The action is performed with
the intersection of the the permissions possessed by the caller's protection
domain, and those possessed by the domains represented by the specified


It says that the intersections of the permissions should be done when checking
accesses. Thus the assigned domains should be checked as well as the execution
stack domains. But the author seems to have understood that he has to keep only
the domains which are in both  contexts (IntersectingDomainCombiner.combine),
which removes domains and thus removes limitations by adding permissions to the
privileged code.

Here is the documentation which helped me understand how this method should

* media.techtarget.com/tss/static/articles/content/dm_security/Java2Sec.pdf
page 9
Taken together, the ProtectionDomains of a thread's assigned and execution
contexts act as a cumulative "Permission filter".

page 11
The AccessController.checkPermission and AccessController.getContext methods
both start out the same: copying the "raw" AccessControlContext (with separate
execution and assigned contexts) using getStackAccessControlContext, and then
combining those contexts in an optimizing manner

* AccessController
The checkPermission method determines whether access is granted or denied based
on the following algorithm:

 i = m;

 while (i > 0) {

      if (caller i's domain does not have the permission)
              throw AccessControlException

      else if (caller i is marked as privileged) {

              if (a context was specified in the call to doPrivileged) 
      i = i - 1;

    // Next, check the context inherited when

    // the thread was created. Whenever a new thread is created, the
    // AccessControlContext at that time is
    // stored and associated with the new thread, as the "inherited"
    // context.


* Android AccessController documentation
The ProtectionDomain of the direct caller of this method, the ProtectionDomains
of all subsequent classes in the call chain and all ProtectionDomains of the
given context are checked to be granted the necessary permission if access
checks are performed.

           Summary: Bad execution and assigned contexts combination in
           Product: classpath
           Version: 0.98
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: classpath
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pierre dot mobde at gmail dot com


reply via email to

[Prev in Thread] Current Thread [Next in Thread]