[JBoss JIRA] (WFLY-12171) EJB Client requires FilePermission for ejb-xa-recovery with security manager enabled
by Ivo Studensky (Jira)
[ https://issues.jboss.org/browse/WFLY-12171?page=com.atlassian.jira.plugin... ]
Ivo Studensky reassigned WFLY-12171:
------------------------------------
Assignee: Ivo Studensky
> EJB Client requires FilePermission for ejb-xa-recovery with security manager enabled
> ------------------------------------------------------------------------------------
>
> Key: WFLY-12171
> URL: https://issues.jboss.org/browse/WFLY-12171
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security Manager
> Reporter: James Perkins
> Assignee: Ivo Studensky
> Priority: Major
>
> The EJB client requires write permissions for the {{$JBOSS_HOME/standalone/data/ejb-xa-recovery}} as well as all files in that directory.
> {code:title=Example Policy}
> grant {
> permission java.io.FilePermission
> "/opt/wildfly/standalone/data/ejb-xa-recovery", "read-write";
> permission java.io.FilePermission
> "/opt/wildfly/standalone/data/ejb-xa-recovery/-", "read-write";
> };
> {code}
> {code:title=Example Exception}
> javax.ejb.EJBException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/work/tc-work/bb15431f347cd651/testsuite/integration/basic/target/wildfly/standalone/data/ejb-xa-recovery" "write")" in code source "(vfs:/content/ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar" from Service Module Loader")
> at org.jboss.ejb.protocol.remote.EJBClientChannel.processInvocation(EJBClientChannel.java:488)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.lambda$handleDone$0(RemoteEJBReceiver.java:91)
> at org.xnio.FinishedIoFuture.addNotifier(FinishedIoFuture.java:79)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.handleDone(RemoteEJBReceiver.java:76)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.handleDone(RemoteEJBReceiver.java:74)
> at org.xnio.IoFuture$HandlingNotifier.notify(IoFuture.java:208)
> at org.xnio.AbstractIoFuture$NotifierRunnable.run(AbstractIoFuture.java:720)
> at org.xnio.IoUtils$2.execute(IoUtils.java:71)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:693)
> at org.xnio.AbstractIoFuture$CompleteState.withNotifier(AbstractIoFuture.java:132)
> at org.xnio.AbstractIoFuture.addNotifier(AbstractIoFuture.java:570)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.processInvocation(RemoteEJBReceiver.java:130)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:491)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocation(RemotingEJBClientInterceptor.java:51)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocation(TransactionPostDiscoveryInterceptor.java:70)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:110)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:67)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:205)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:333)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:187)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> at com.sun.proxy.$Proxy283.twoSecondEcho(Unknown Source)
> at org.jboss.as.test.integration.ejb.client.descriptor.EchoBean.twoSecondEcho(EchoBean.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:237)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:362)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:591)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:572)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:205)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/work/tc-work/bb15431f347cd651/testsuite/integration/basic/target/wildfly/standalone/data/ejb-xa-recovery" "write")" in code source "(vfs:/content/ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
> at org.wildfly.security.manager.WildFlySecurityManager.checkWrite(WildFlySecurityManager.java:377)
> at java.io.File.mkdir(File.java:1311)
> at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry$XAResourceRegistryFile.<init>(FileSystemXAResourceRegistry.java:207)
> at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry.getXAResourceRegistryFile(FileSystemXAResourceRegistry.java:121)
> at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider.getXAResourceRegistry(JBossLocalTransactionProvider.java:160)
> at org.wildfly.transaction.client.XAOutflowedResources.getOrEnlist(XAOutflowedResources.java:57)
> at org.wildfly.transaction.client.RemoteTransactionContext.outflowTransaction(RemoteTransactionContext.java:222)
> at org.jboss.ejb.protocol.remote.EJBClientChannel.writeTransaction(EJBClientChannel.java:586)
> at org.jboss.ejb.protocol.remote.EJBClientChannel.processInvocation(EJBClientChannel.java:384)
> ... 96 more
> {code}
> Full chat conversion: https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
> {quote}
> David Lloyd: the notifier is running in the same thread because the response was available quickly enough
> David Lloyd: when that happens you get the permission exception because the test class doesn't have the filesystem permissions
> David Lloyd: the easy fix would be to grant that perm to the test
> David Lloyd: slightly more elegant would be to introduce a new permission that would grant the ability to outflow transactions and grant that permission, and use a doPrivileged inside the outflow code
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFLY-12446) Memory leak in StatelessSessionComponent
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-12446?page=com.atlassian.jira.plugin... ]
Matěj Novotný commented on WFLY-12446:
--------------------------------------
Alright, I think I see the issue - *doesn't look like a bug but a user error* . Like I said above, when you retrieve {{@Dependent}} instances via {{Instance}}, you need to keep reference to them and destroy them. Note that every invocation of {{Instance.get()}} gives you new, different instance of the bean that you need to destroy and a for cycle over {{Instance}} means you invoke {{get()}} in order to grab each of those beans.
Therefore in the following code(from example), two sets of {{Command}} instances are created but only one is destroyed (mind the NOTEs I added to the code):
{code}
public CommandResult executeCommand(String commandName, String parameter) {
CommandResult result = null;
logger.infof("CommandService: searching for command -> %s", commandName);
if (commands != null) {
// search command
for (Command command : commands) {
// NOTE - this instantiates the command beans but no destroy is invoked within this for cycle!
String name = command.getName();
logger.infof(" ... %s", name);
// execute if found
if (commandName.equals(name)) {
logger.infof(" ... found command, executing %s", name);
result = command.execute(name + ": " + parameter);
break;
}
}
// command found?
if (result == null) {
logger.infof("CommandService: command not found -> %s", commandName);
result = new CommandResult(0L, "Undefined");
}
// avoid memory leak
logger.info("destroying commands to avoid memory leak!");
for (Command command : commands) {
// NOTE - this is redundant, it created new/different instances of Command and destroys those only!
commands.destroy(command);
}
} else {
logger.info("CommandService: no commands available!");
}
return result;
}
{code}
You can fix this easily by changing the first for cycle as follows and dropping the second one:
{code}
for (Command command : commands) {
String name = command.getName();
logger.infof(" ... %s", name);
// execute if found
if (commandName.equals(name)) {
logger.infof(" ... found command, executing %s", name);
result = command.execute(name + ": " + parameter);
// destroy the instance
commands.destroy(command);
break;
} else {
// destroy the instance
commands.destroy(command);
}
}
{code}
Fixing the code like this, jconsole shows me much less memory used during the load test and especially not hanging around afterwards.
> Memory leak in StatelessSessionComponent
> ----------------------------------------
>
> Key: WFLY-12446
> URL: https://issues.jboss.org/browse/WFLY-12446
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Reporter: Joerg Baesner
> Assignee: Cheng Fang
> Priority: Major
> Attachments: dump-weld.png, playground-jee8.zip, server.log.gz, wfly-12446-heap-dump.png
>
>
> When running the attached reproducer application and doing a memory analysis afterwards, it looks like a memory leak, e. g.
> {code}
> One instance of "org.jboss.as.ejb3.component.stateless.StatelessSessionComponent" loaded by "org.jboss.modules.ModuleClassLoader @ 0x5e0fbc2e0" occupies 936,593,520 (96.13%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentLinkedQueue$Node" loaded by "<system class loader>".
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean
by Diana Vilkolakova (Jira)
[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ]
Diana Vilkolakova commented on WFLY-11604:
------------------------------------------
{quote} I think we should get an issue created to see if there is a way to fix this for the Elytron case without breaking the fix for JBEAP-9744.{quote} I created an issue WFLY-12537 for this purpose.
I also created WFLY-12538 to address the fact that scenario #1 returns 'non-anonymous' principal when Elytron is enabled, which is incorrect. I am closing this issue since it is superceded by WFLY-12537 and WFLY-12538.
> Non-anonymous principal is not propagated from EJB context to CDI bean
> ----------------------------------------------------------------------
>
> Key: WFLY-11604
> URL: https://issues.jboss.org/browse/WFLY-11604
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Security
> Affects Versions: 14.0.1.Final, 15.0.1.Final
> Reporter: Nikoleta Ziakova
> Priority: Critical
>
> This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal.
> However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...].
> The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFLY-12538) Principal injected in a secured bean is different when Elytron is activated
by Diana Vilkolakova (Jira)
Diana Vilkolakova created WFLY-12538:
----------------------------------------
Summary: Principal injected in a secured bean is different when Elytron is activated
Key: WFLY-12538
URL: https://issues.jboss.org/browse/WFLY-12538
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Diana Vilkolakova
Assignee: Diana Vilkolakova
This is a follow up on WFLY-11604. Principal should be anonymous when injected inside a bean that has RunAsPrincipal annotation but no incoming RunAs identity. This is because the call does not pass to another EJB and therefore there is no outbound call. This works for legacy but not for Elytron.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (JBEE-236) Update MANIFEST for JASPI
by Darran Lofthouse (Jira)
Darran Lofthouse created JBEE-236:
-------------------------------------
Summary: Update MANIFEST for JASPI
Key: JBEE-236
URL: https://issues.jboss.org/browse/JBEE-236
Project: JBoss Enterprise Spec APIs
Issue Type: Task
Components: jboss-jaspi-api
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: jboss-jakarta-jaspi-api_spec-2.0.0.Final
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFLY-12537) Incoming RunAsPrincipal is not being propagated to an unsecured EJB
by Diana Vilkolakova (Jira)
Diana Vilkolakova created WFLY-12537:
----------------------------------------
Summary: Incoming RunAsPrincipal is not being propagated to an unsecured EJB
Key: WFLY-12537
URL: https://issues.jboss.org/browse/WFLY-12537
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Diana Vilkolakova
Assignee: Diana Vilkolakova
This is a follow-up on WFLY-11604. When Elytron is activated, run-as-principal identity is not being propagated the same way it was for legacy. For JBEAP-9744, we updated EJBContext.getCallerPrincipal() so that when called from an unsecured bean with no incoming runas identity, an `anonymous` principal will be returned. The issue WFLY-11604 discovered that EJBContext.getCallerPrincipal is returning 'anonymous' when called on an unsecured EJB even when incoming RunAsPrincipal identity should have been propagated. This issue is to see whether this can be fixed without breaking the fix for JBEAP-9744.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months