On 07/22/2013 04:57 PM, Daniel Kulp wrote:
> 
> On Jul 19, 2013, at 6:06 PM, Alessio Soldano <[email protected]> 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.

Ah, right, didn't remember of that. Will create a new method in
ReflectionUtil for this.


>> * "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.

OK, thanks. Yes, I meant to say that elsewhere setContextClassLoader is
used within privileged actions, hence no need for the user to set the
permission.

Thanks
Alessio


-- 
Alessio Soldano
Web Service Lead, JBoss

Reply via email to