Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
framework-1.0.4
-
None
Description
Subject.doAs allows to perform work as a particular Subject. It first retrieves the current Thread's AccessControlContext via AccessController.getContext, and then instantiates a new AccessControlContext using the retrieved context along with a new SubjectDomainCombiner (constructed using the provided Subject). Finally, this method invokes AccessController.doPrivileged, passing it the provided PrivilegedAction, as well as the newly constructed AccessControlContext.
The issue is that the SubjectDomainCombiner does update the relevant ProtectionDomains with the Principals from the Subject associated with this SubjectDomainCombiner by creating a new ProtectionDomain instance for each ProtectionDomain in the currentDomains array. Each new ProtectionDomain instance is created using the CodeSource, Permissions and ClassLoader from the corresponding ProtectionDomain in currentDomains, as well as with the Principals from the Subject associated with this SubjectDomainCombiner.
This doesn't work well with the OSGi spec due to the fact that each bundle (or revision to be precise) has its own custom ProtectionDomain which is lost when Subject.doAs is used. There is a way to make it work for most scenarios namely, make the custom ProtectionDomain return a speciall PermissionCollection because that is reused by the ProtectionDomain created by the SubjectDomainCombiner if no custom policy is installed (in the later case a different workaround would be needed).
Currently, Felix doesn't work when Subject.doAs is used and security is enabled.