svendiedrichsen / jollyday

Jollyday - A holiday API
Other
189 stars 114 forks source link

Too extensive permission required #82

Closed ghost closed 5 years ago

ghost commented 5 years ago

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.

permission java.util.PropertyPermission "*", "read,write";

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.

Instead of ...

...
Properties systemProps = System.getProperties();
String configURLs = systemProps.getProperty(CONFIG_URLS_PROPERTY);
...

... you can just do this ...

...
String configURLs = System.getProperty(CONFIG_URLS_PROPERTY);
...

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.

ghost commented 5 years ago

Nevermind. This was already fixed in v0.5.4.