cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <asold...@redhat.com>
Subject Running JAXWS client with security manager on
Date Fri, 19 Jul 2013 22:06:36 GMT
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

Mime
View raw message