[
https://issues.apache.org/jira/browse/SSHD-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-668.
---------------------------------
Resolution: Fixed
Fix Version/s: 1.3.0
Thanks for the diagnosis and the suggested solution - I tested in on the main
code and indeed it seems to work without a problem, so I have no problem
committing it to the master branch.
> AccessControlException running under OSGi container
> ---------------------------------------------------
>
> Key: SSHD-668
> URL: https://issues.apache.org/jira/browse/SSHD-668
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 1.2.0
> Reporter: Dave Roberts
> Assignee: Goldstein Lyor
> Fix For: 1.3.0
>
>
> Using a minimalistic version of the "SSHD in 5 minutes", I was able to run
> this up and connect using WinSCP no problem.
> I then added my JAR as a bundle into an OSGi container. This deployed OK, but
> as soon as I tried to connect, the following exception was thrown:-
> {noformat}
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "modifyThreadGroup")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at
> java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at
> com.sun.enterprise.security.ee.J2EESecurityManager.checkAccess(J2EESecurityManager.java:98)
> at java.lang.ThreadGroup.checkAccess(ThreadGroup.java:315)
> at java.lang.Thread.init(Thread.java:391)
> at java.lang.Thread.init(Thread.java:349)
> at java.lang.Thread.<init>(Thread.java:675)
> at
> org.apache.sshd.common.util.threads.ThreadUtils$SshdThreadFactory.newThread(ThreadUtils.java:174)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:612)
> at
> java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:925)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1357)
> at
> sun.nio.ch.AsynchronousChannelGroupImpl.executeOnPooledThread(AsynchronousChannelGroupImpl.java:188)
> at sun.nio.ch.Invoker.invokeIndirectly(Invoker.java:212)
> at sun.nio.ch.Invoker.invokeIndirectly(Invoker.java:313)
> at
> sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl$AcceptTask.completed(WindowsAsynchronousServerSocketChannelImpl.java:272)
> at sun.nio.ch.Iocp$EventHandlerTask.run(Iocp.java:397)
> at java.lang.Thread.run(Thread.java:745)
> at sun.misc.InnocuousThread.run(InnocuousThread.java:74)
> {noformat}
> I'm no expert on the java security model, but I traced how the initial thread
> was created successfully, so modified the thread instantiation in
> {{SshdThreadFactory.newThread}} to run in priviledged mode:-
> {code:java}
> try {
> t = AccessController.doPrivileged(new
> PrivilegedExceptionAction<Thread>() {
> public Thread run() {
> return new Thread(group, r, namePrefix +
> threadNumber.getAndIncrement(), 0);
> }
> });
> } catch (PrivilegedActionException e1) {
> //Exception from privileged code block, re-throwing...
> throw (RuntimeException) e1.getException();
> }
> {code}
> This resolved the issue and also worked correctly in standalone mode
> (invoking my SSHD implementation from a main method). Of course there may be
> side effects that I'm not aware of when doing the above when it's not
> required, in which case it can obviously be wrapped in a test that loads the
> Security Manager and checks whether the permission is required.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
