Bug 1128815 - Git + SSH Cloning of Business Central Git Repository Fails if Java Security Manager is Enabled
Summary: Git + SSH Cloning of Business Central Git Repository Fails if Java Security M...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.0.2
Hardware: Unspecified
OS: All
high
low
Target Milestone: ER4
: 6.1.0
Assignee: Alexandre Porcelli
QA Contact: Karel Suta
URL:
Whiteboard:
Depends On: 1175682
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-11 15:21 UTC by Joe Hunt
Modified: 2020-03-27 19:12 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:12:37 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Apache JIRA SSHD-332 0 None None None Never

Description Joe Hunt 2014-08-11 15:21:43 UTC
Description of problem: Cloning the BPM Suite Business Central git repository using the ssh protocol does not work if the Java Security Manager is enabled. Changes cannot be pushed to the Business Central git repository via the Business Central ssh server if you cannot clone the repository using ssh.

Version-Release number of selected component (if applicable): BPM Suite 6.0.1 and 6.0.2.

How reproducible:  If the Java Security Manager is enabled when starting Business Central running in JBoss EAP 6.1, it is not possible to clone a git repository from Business Central using the ssh protocol.  If the Java Security Manager is not enabled (or disabled), it is possible to clone a Business Central git repository using the ssh protocol.

Steps to Reproduce:
1. Enable the Java Security Manager when installing the BPM Suite or post installation by adding the following line to standalone.conf.bat: set "SECURITY_OPTS=-Djava.security.manager "-Djava.security.policy=%DIRNAME%security.policy" "-Dkie.security.policy=%DIRNAME%kie.policy""
2. Start BPM Suite/Business Central (i.e., EAP 6.1) with standalone.bat.
3. Attempt to clone a git repository using ssh from the command line or with Eclipse.  For example, from the command line, issue the following command: "git clone ssh://myname@localhost:8001/repository1"
4. An AccessControlException will be logged on the server and the git clone command will not complete (i.e., hang).
5. Shut down EAP 6.1.
6. Disable the Java Security Manager by commenting out the security options set in standalone.conf.bat in step 1.
6. Restart the BPM Suite/Business Central with standalone.bat.
7. Attempt to clone a git repository in Business Central using ssh by repeating step 3. The bit clone command will complete successfully.


Actual results:  If the Java Security Manager is enabled, the git clone command will hang and a Business Central repository will fail to be cloned.  

Expected results:  A Business Central git repository should be able to be cloned using the ssh protocol and changes should be able to be pushed to the repository.


Additional info: If the Java Security Manager is not enabled, the git clone command using the ssh protocol will complete and a Business Central repository will be successfully cloned.  This appears to be related to Apache Mina bug sshd-332.

Comment 2 Alexandre Porcelli 2014-12-29 20:01:06 UTC
We've updated sshd to 0.12.0 for 6.1.x product (sshd-332 is fixed on this version).

Comment 3 Karel Suta 2015-01-28 13:43:53 UTC
Cannot be verified in 6.1.0.ER4, testing blocked by BZ1175682 .

Comment 4 Karel Suta 2015-03-10 09:32:45 UTC
Tried with 6.1.0.ER6, but still doesn't work.

With security manager disabled it is possible to clone repository using SSH, when security manager is enabled then it isn't possible to authenticate - got message "Permission denied, please try again."

Security manager enabled by adding this line to standalone.conf:
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.policy-permissions=true -Djava.security.manager \"-Djava.security.policy=$DIRNAME/security.policy\" \"-Dkie.security.policy=$DIRNAME/kie.policy\""

Comment 5 Chris Dolphy 2016-03-08 23:22:33 UTC
The change in sshd-332 appears to have just been wrapping some of the nio call with a AccessController.doPrivileged block.  This means that the caller doesn't need to have the permission to do the nio, just the sshd library.  

End result is that some permission might still need to be added to the policy, but at least the application won't have to add the same permission.

Can you add -Djava.security.debug=access:failure and reproduce the issue?  This should give an error message that will help determine the missing permission.


Note You need to log in before you can comment on or make changes to this bug.