Community
Participate
Working Groups
From Mike Mansell: I was doing some experimental work with Equinox and the incubator Config Admin service and running under a Security Manager. I found that a bundle that has restricted permissions incorrectly fails when manipulating configuration data. Basically, if Bundle A has only permission to get the ConfigurationAdmin service and CONFIGURE permissions ie. ( org.osgi.framework.ServicePermission "org.osgi.service.cm.ConfigurationAdmin" "GET" ) ( org.osgi.service.cm.ConfigurationPermission "*" "CONFIGURE" ) Then, it's able to get the Configuration object, but when it attempts to update it, there is a permission failure within the Config Admin. Specifically, when it attempts to access the file system to write the updated properties, (ie. java.io.File access) the normal AccessController verifies that both the Config Admin AND Bundle A have the permission to access the file. Bundle A's permissions should have no bearing on this as the fact that it's a File store is internal to this implementation of the Config Admin.
Created attachment 85996 [details] Possible fix to the security problem I've walked through the different 'public' access points to the Config Admin service, and found that there are only 3 places that need to have a minor change. Basically, anywhere that the ConfigurationStore is accessed from public APIs and attempt to change the permanent store (which is only within ConfigurationImpl). These 3 places need to have a AccessController.doPriviledged() wrapper added to stop the AccessController from checking permissions beyond the Config Admin (ie. prevent it from checking Bundle A). This patch contains those changes.
I've checked a fix into HEAD. I restricted the privileged section just to the configuration store but otherwise it should perform correctly. This passes the unit tests however I I have not had a chance to test this properly with a SecurityManager in place similar to what you describe so I'm hesitant to mark FIXED. Mike, could you try the version from HEAD to confirm?
Adding contributed key word. Simon, I assume you based the fix off the contributed fix from Mike?
I've checked out the latest, and yes, it does work in my SecurityManager. I don't have a test case for delete, but the update works great.
re: contributed Yes. Thanks for the patch Mike.
