Bug 1021547

Summary: Incorrect credentials taken for processing recovery
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Ondrej Chaloupka <ochaloup>
Component: JCAAssignee: Stefano Maestri <smaestri>
Status: CLOSED EOL QA Contact: Ondrej Chaloupka <ochaloup>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.4.0CC: cdewolf, hhovsepy, jpederse, mnovak
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-19 12:44:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
server.log with trace on whole server none

Description Ondrej Chaloupka 2013-10-21 13:36:22 UTC
When you use the xa-datasource with credentials used for recovery in the following way:

<security>
  <user-name>user0</user-name>
  <password>user0</password>
</security>
<recovery>
  <recover-credential>
    <user-name>usercrash</user-name>
    <password>usercrash</password>
  </recover-credential>
</recovery>

then the recovery uses 'user0' instead of 'usercrash'. Which is incorrect behavior.

Comment 2 Ondrej Chaloupka 2014-05-19 11:39:57 UTC
Hi Jesper,

please, what is status of this issue. We are still hitting it on running tests for 6.3.0.

Thank you
Ondra

Comment 3 Jesper Pedersen 2014-05-19 12:33:52 UTC
Needs investigation in EAP layer - DEBUG log of deployer chain shows the user name "RecoverUser=blah"

Comment 4 Stefano Maestri 2014-05-19 15:20:11 UTC
I've added an XA datasource with this configuration and it seems to work fine. See DEBUG log:
17:16:30,975 DEBUG [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-6) RecoverUser=usercrash
17:16:30,976 DEBUG [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-6) RecoverSecurityDomain=null
17:16:30,997 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-6) Adding datasource: java:/H2XADS
17:16:31,002 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:jboss/datasources/ExampleDS
17:16:31,009 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
17:16:31,001 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:/H2XADS]
17:16:31,180 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
17:16:31,180 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
17:16:31,181 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.3.0.Beta1 (AS 7.4.0.Final-redhat-SNAPSHOT) started in 2538ms - Started 157 of 195 services (56 services are lazy, passive or on-demand)


17:18:40,846 DEBUG [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) Recovery user name=usercrash
17:18:40,849 DEBUG [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) Recovery Subject=Subject:
	Principal: usercrash
	Private Credential: javax.resource.spi.security.PasswordCredential@c3b0d380

17:18:40,853 DEBUG [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) Open managed connection (Subject:
	Principal: usercrash
	Private Credential: javax.resource.spi.security.PasswordCredential@c3b0d380
)
17:18:40,963 DEBUG [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) Open connection (org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@2999d466, Subject:
	Principal: usercrash
	Private Credential: javax.resource.spi.security.PasswordCredential@c3b0d380
)
17:18:40,967 DEBUG [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) Closing connection for recovery check (org.jboss.jca.adapters.jdbc.jdk6.WrappedConnectionJDK6@3539f4f9)
17:18:40,968 DEBUG [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) Force close=false
17:18:40,969 DEBUG [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) Recovery XAResource=XAResourceWrapperImpl@3eeacfc0[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@2999d466 pad=false overrideRmValue=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:/H2XADS] for java:/H2XADS

Comment 5 Ondrej Chaloupka 2014-05-20 14:07:57 UTC
Hi Stefano,

it seems to me that the incorrect user for real recovery is used either. I took the trace log from the test run and this is the output.

---
14:07:14,792 INFO  [stdout] (EJB default - 5) rule.debug{org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResource_prepare_crashatENTRY} : killing JVM
---
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.internals.XA] (Periodic Recovery) SQLServerXADataSource:1 user:crash0
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.internals.XA] (Periodic Recovery) SQLServerXADataSource:1 user:crash0SQLServerXAConnection:2
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.internals.XA] (Periodic Recovery) SQLServerXADataSource:1 Start get physical connection.
14:07:33,352 FINE  [com.microsoft.sqlserver.jdbc.internals.XA] (Periodic Recovery) SQLServerXADataSource:1 End get physical connection, ConnectionID:3 ClientConnectionId: 4bcd86a4-f0e0-4e47-98b6-d0ac43ca5079
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.DataSource] (Periodic Recovery) RETURN SQLServerXAConnection:2
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.internals.SQLServerDataSource] (Periodic Recovery) SQLServerXAConnection:2 user:(default).
14:07:33,352 FINE  [com.microsoft.sqlserver.jdbc.internals.SQLServerDataSource] (Periodic Recovery) SQLServerXAConnection:2 Physical connection, ConnectionID:3 ClientConnectionId: 4bcd86a4-f0e0-4e47-98b6-d0ac43ca5079
14:07:33,352 FINE  [com.microsoft.sqlserver.jdbc.internals.SQLServerDataSource] (Periodic Recovery) SQLServerXAConnection:2 proxy  ProxyConnectionID:2 is returned.
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) ENTRY
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) RETURN 2
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) ENTRY
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) RETURN false
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) ENTRY
14:07:33,352 FINE  [com.microsoft.sqlserver.jdbc.internals.SQLServerDatabaseMetaData] (Periodic Recovery)  SQLServerDatabaseMetaData:2 created by (ConnectionID:3 ClientConnectionId: 4bcd86a4-f0e0-4e47-98b6-d0ac43ca5079)
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) RETURN  SQLServerDatabaseMetaData:2
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) ENTRY
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) RETURN  SQLServerDatabaseMetaData:2
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) ENTRY
14:07:33,352 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) RETURN false
14:07:33,353 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) ENTRY
14:07:33,353 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) RETURN  SQLServerDatabaseMetaData:2
14:07:33,353 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) ENTRY
14:07:33,353 FINER [com.microsoft.sqlserver.jdbc.Connection] (Periodic Recovery) RETURN false
14:07:33,353 FINER [com.microsoft.sqlserver.jdbc.internals.SQLServerDataSource] (Periodic Recovery) SQLServerXAConnection:2ConnectionID:3 ClientConnectionId: 4bcd86a4-f0e0-4e47-98b6-d0ac43ca5079
14:07:33,353 FINE  [com.microsoft.sqlserver.jdbc.internals.XA] (Periodic Recovery)  XAResourceID:2 created by (SQLServerXAConnection:2)
---
14:07:33,736 FINE  [com.microsoft.sqlserver.jdbc.internals.SQLServerException] (Periodic Recovery) *** SQLException: com.microsoft.sqlserver.jdbc.SQLServerException: The EXECUTE permission was denied on the object 'xp_sqljdbc_xa_recover', database 'master', schema 'dbo'. Msg 229, Level 14, State 5, The EXECUTE permission was denied on the object 'xp_sqljdbc_xa_recover', database 'master', schema 'dbo'.
14:07:33,737 FINER [com.microsoft.sqlserver.jdbc.internals.XA] (Periodic Recovery)  XAResourceID:2 exception:com.microsoft.sqlserver.jdbc.SQLServerException: The EXECUTE permission was denied on the object 'xp_sqljdbc_xa_recover', database 'master', schema 'dbo'.

Comment 6 Ondrej Chaloupka 2014-05-20 14:11:07 UTC
Created attachment 897619 [details]
server.log with trace on whole server

Comment 7 Jesper Pedersen 2014-05-20 14:20:50 UTC
The recovery subject created:

14:07:31,484 DEBUG [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) Recovery Subject=Subject:
	Principal: crashrec
	Private Credential: javax.resource.spi.security.PasswordCredential@851d2612

So the JDBC driver likely overrides it.

Comment 8 Ondrej Chaloupka 2014-05-21 08:30:07 UTC
OK, from I can find in the log I admin that this could be an issue in jdbc driver.

I can say that the recovery is proceeded at the end and just the server log is polluted with exception warnings. Which means that the recovery functionality is not threatened by this issue.

As I do not have time for more detailed investigation now I'm passing that to "TBD". I will be needed to check who and why switches the connection for doing recovery. Especially it's strange that we do not get the same exceptions to log when we use security domain to get credentials to database login.

Comment 9 Ondrej Chaloupka 2014-10-17 11:02:46 UTC
I've checked the issue and I'm putting this back to JCA.

The problem seems to be in class XAResourceRecoveryImpl#getXAResources()
Connection on line 176 is opened with the newly created subject but returned XAResource contains old properties (see props under XAResource implementation constructor) which contain 'crash0' instead of credentials to 'crashrec' which is expected to be used for recovery.

For mentioned code see:
https://github.com/ironjacamar/ironjacamar/blob/08e73c195beadb05ebddf2ea0f34a22e43ff5a4c/core/src/main/java/org/jboss/jca/core/tx/jbossts/XAResourceRecoveryImpl.java#L177

Comment 10 Jesper Pedersen 2014-10-24 14:22:02 UTC
mc.getXAResource() is from the underlying Enterprise Information System - f.ex. the JDBC driver

Comment 11 Ondrej Chaloupka 2014-10-29 07:50:25 UTC
Hi Stefano,

thanks for pointing this out. I missed that. But when I looked to code a bit more the issue seems to be really on JCA layer.

The next suspicious is class BaseWrapperManagedConnectionFactory where connection properties are created. This returns connection properties without taking into consideration the subject. 

See:
https://github.com/ironjacamar/ironjacamar/blob/08e73c195beadb05ebddf2ea0f34a22e43ff5a4c/adapters/src/main/java/org/jboss/jca/adapters/jdbc/BaseWrapperManagedConnectionFactory.java#L955

o.