On Jul 19, 2013, at 6:06 PM, Alessio Soldano <asold...@redhat.com> wrote: > 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.
Should these all be moved to using the calls in ReflectionUtil? We already have a bunch of methods on ReflectionUtil that handle the doPriviledged call for the various reflection based things we need. > * "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. We call setContextClassLoader in other places as well, but they all go through ClassLoaderUtils which again has the Access stuff in it. I *THINK* we didn't use it in LogUtils due to a potentially circular issue of needing Logging prior to so of the other things that are in ClassLoaderUtils. Thus, this is likely the right way to go. > * 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). OK. > 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? Sure. That works. Dan > 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
