We are using Jolliday in our current project. We are also required to run our application with the Java security manager enabled. That's why we ran into an unexpected AccessControlException because of Jolliday. Our customer demands to point out all permissions that are required by our application. Because of the security driven application management of our customer, we are not allowed to use wildcard permissions without effortful justifications.
Our problem is located in URLConfigurationProvider.getProperties().
@Override
public Properties getProperties() {
Properties properties = new Properties();
Properties systemProps = System.getProperties();
String configURLs = systemProps.getProperty(CONFIG_URLS_PROPERTY);
if (configURLs != null) {
String[] strConfigURLs = configURLs.split(",");
for (String strURL : strConfigURLs) {
readPropertiesFromURL(properties, strURL);
}
}
return properties;
}
Using System.getProperties() requires a java.util.PropertyPermission with a wildcard.
The point is, this is not necessary! The method URLConfigurationProvider.getProperties() is invoking System.getProperties() just to get the single property de.jollyday.config.urls out of that.
The result would be exactly the same. You don't need the detour by using the result of System.getProperties(). You can read the required property directly. This would just require the permission to read(!) a property. We have that permission already. No discussion with our customer would be needed.
Since there is absolutely no way to override this method, because the URLConfigurationProvider is a private field in ConfigurationProviderManager and there is no way the set a different implementation of URLConfigurationProvider. And the ConfigurationProviderManager itself is a private and static field in HolidayManager. Simply put: There is no technical option to around that. Nothing but to fix this in the master code base or to create a fork.
We are using Jolliday in our current project. We are also required to run our application with the Java security manager enabled. That's why we ran into an unexpected
AccessControlException
because of Jolliday. Our customer demands to point out all permissions that are required by our application. Because of the security driven application management of our customer, we are not allowed to use wildcard permissions without effortful justifications.Our problem is located in
URLConfigurationProvider.getProperties()
.Using
System.getProperties()
requires ajava.util.PropertyPermission
with a wildcard.The point is, this is not necessary! The method
URLConfigurationProvider.getProperties()
is invokingSystem.getProperties()
just to get the single propertyde.jollyday.config.urls
out of that.Instead of ...
... you can just do this ...
The result would be exactly the same. You don't need the detour by using the result of
System.getProperties()
. You can read the required property directly. This would just require the permission to read(!) a property. We have that permission already. No discussion with our customer would be needed.Since there is absolutely no way to override this method, because the
URLConfigurationProvider
is a private field inConfigurationProviderManager
and there is no way the set a different implementation ofURLConfigurationProvider
. And theConfigurationProviderManager
itself is a private and static field inHolidayManager
. Simply put: There is no technical option to around that. Nothing but to fix this in the master code base or to create a fork.