Hi, I've running some tests with Apache CXF in a security manager enabled environment. In particular, I'm focussing on having JAXWS clients properly run in-container on WildFly application server (which CXF is integrated through JBossWS). As part of the process, I've been analysing the permissions required by CXF at runtime as soon as I stumbled in a java.security.AccessControlException: at CXF-5142 [1] you find a first step patch for most of the issues I noticed so far (more likely to come later). I didn't commit it yet to give people a chance of reviewing first. Here is a brief discussion on the changes:
* "accessDeclaredMembers" permission: I moved a bunch of class.getDeclaredMethod() calls into privileged actions; they're basically all related to JAXB processing or for looking up "Asynch" methods, don't honestly see why we shouldn't do this way. * "setContextClassLoader" permission: LogUtils is setting the thread context classloader to create the logger instance and restoring the former classloader before returning. I believe the classloader set operation should be in privileged blocks, this looks possibly the only place were we require the user to set this permission. * bus extensions resolution and jar read permissions: this is possibly a subtle one; I'd need to be able to create the in container jaxws client without asking the user to manually set read permissions for any of the container jar components. Currently the cxf jars read permissions are checked *twice* in ExtensionManagerImpl::load(String resource, ClassLoader l), when getting the resources enum from the classloader and then when opening a stream from each of them. I would make the url.openStream() call run in a privileged block as that's what can't be controlled by the underlying container in terms of permissions. The container (WildFly here) can properly deal with permissions when getting the resources list instead (as a custom classloader would be in use there). Besides for the items above, there's another issue I noticed and I didn't have time to try fixing yet, the URIResolver#tryFileSystem one. That method is used e.g. during wsdl load; the problem is that it does multiple tries to figure out how to read the passed uri. As a consequence of that, existence of multiple "wrong" files is checked and each check requires read permission (the file existence checks on filesystem are performed also for e.g. http addresses...). So I think expecting the user to set all those read permissions is not good at all. Ideally I would imagine a solution where we define a new permission (say "CXFResolveURI"), check for that and if it's granted we run the file.exists() call within privileged actions. What do you think? More stuff likely to come, but I just wanted to get the discussion started... Thanks Alessio [1] https://issues.apache.org/jira/browse/CXF-5142 -- Alessio Soldano Web Service Lead, JBoss
