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.
Hi Jesper, please, what is status of this issue. We are still hitting it on running tests for 6.3.0. Thank you Ondra
Needs investigation in EAP layer - DEBUG log of deployer chain shows the user name "RecoverUser=blah"
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
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'.
Created attachment 897619 [details] server.log with trace on whole server
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.
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.
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
mc.getXAResource() is from the underlying Enterprise Information System - f.ex. the JDBC driver
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.