bug-classpath
[Top][All Lists]
Advanced

[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
AccessControlContext.

http://java.sun.com/javase/6/docs/api/java/security/AccessController.html#doPrivileged%28java.security.PrivilegedExceptionAction,%20java.security.AccessControlContext%29

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
work:

* 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
Documentation:http://java.sun.com/javase/6/docs/api/java/security/AccessController.html#doPrivileged%28java.security.PrivilegedExceptionAction,%20java.security.AccessControlContext%29
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) 
                 context.checkPermission(permission)
              return;
      }
      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.


 inheritedContext.checkPermission(permission);


* Android AccessController documentation
http://developer.android.com/reference/java/security/AccessController.html#doPrivileged%28java.security.PrivilegedExceptionAction%3CT%3E,%20java.security.AccessControlContext%29
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
                    VMAccessController.getContext
           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


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44007





reply via email to

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