November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ] Ken Wills commented on WFLY-5227: --------------------------------- Updated, working core diff here, with GAV change and a manual fixup of the metadata dep removal and additional loggers added previously: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-... As part of some rebase weirdness, removing commits up to 'de72c28 WFLY-401 Add the security manager subsystem' leaves some legacy code around (Security actions). I could either continue with the truncated rebase and manually remove these files at the end, or just include the complete history. I think it makes sense to go with the complete histrory. Core boots and works, both with and without -secmgr, though I don't know how to test it further than that :) > Move security-manager subsystem from WildFly to WildFly Core > ------------------------------------------------------------ > > Key: WFLY-5227 > URL: https://issues.jboss.org/browse/WFLY-5227 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Reporter: Josef Cacek > Assignee: Ken Wills > Priority: Critical > > It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core. > More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2073) Increase the likelihood of ManagedProcess kill invoking the OS kill command when multiple HCs are on the system

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2073: ---------------------------------------- Summary: Increase the likelihood of ManagedProcess kill invoking the OS kill command when multiple HCs are on the system Key: WFCORE-2073 URL: https://issues.jboss.org/browse/WFCORE-2073 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor The ManagedProcess kill() method relies on a scan of running processes that have a command line with -D[<processname>] in the command line, refusing to do the OS kill if > 1 such process is found. This is troublesome if you have > 1 HC on the machine, as they are likely to use the same process names (e.g. "Server:server-one"). So the 'kill' doesn't happen, and destroy() gets used instead. Destroy doesn't seem as strong, as it seems to not prevent shutdown hook execution, leaving open the possibility of hangs. Perhaps the PC could generate a random int or even a short and include that as a param on the command line as well, then use that as part of the discrimination check. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2072) ManagedProcess destroy should use Process.destroyForcibly().

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2072: ---------------------------------------- Summary: ManagedProcess destroy should use Process.destroyForcibly(). Key: WFCORE-2072 URL: https://issues.jboss.org/browse/WFCORE-2072 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Since JDK 8, the contract of java.lang.Process.destroy() has changed to no longer specify that the destroy must be forcible. A new destroyForcibly() method was added, so we should use that. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7662) CLIENT-CERT authentication doesn't work

by Rostyslav Smirnov (JIRA)

[ https://issues.jboss.org/browse/WFLY-7662?page=com.atlassian.jira.plugin.... ] Rostyslav Smirnov commented on WFLY-7662: ----------------------------------------- It is caused by HTTP/2 enablement in Wildfly 10.1.0. Browser doesn't present a certificate when establishing the connection, so [ClientCertAuthenticationMechanism|https://github.com/undertow-io/undertow...] renegotiates, triggering browser to present certificate dialog prompt. This doesn't happen in Wildfly 10.1.0 due to [Http2SslSessionInfo|https://github.com/undertow-io/undertow/blob/1.4.0.Final/core/src/main/java/io/undertow/server/protocol/http2/Http2SslSessionInfo.java#L91] not supporting renegotiation. > CLIENT-CERT authentication doesn't work > --------------------------------------- > > Key: WFLY-7662 > URL: https://issues.jboss.org/browse/WFLY-7662 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Java 1.8.0_112 > Reporter: Rostyslav Smirnov > Assignee: Stuart Douglas > > When accessing a web application secured by CLIENT-CERT authentication, a browser no longer presents certificate dialog prompt, always displays response 403 Forbidden instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2003) replacement expression in access-control

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2003?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2003: ------------------------------------- Issue Type: Enhancement (was: Feature Request) > replacement expression in access-control > ---------------------------------------- > > Key: WFCORE-2003 > URL: https://issues.jboss.org/browse/WFCORE-2003 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 2.1.0.Final > Environment: EAP7.0.3 > Reporter: Hisanobu Okuda > Assignee: Brian Stansberry > > Our customer wants to use replacement expression in `<access-control/>`: > {code} > ${env.VARNAME} for environemt vars > ${VARNAME} for system properties > ${VAULT::BLOCK::attribute::1} for vars stored inside jboss vault > {code} > Example: > while adding group in for any role like (SuperUser) . > {code} > /core-service=management/access=authorization/role-mapping=SuperUser/include="group_admin":add(name="${ldap_admin_grp}", type=GROUP) > {code} > resulting : > {code} > <role name="SuperUser"> > <include> > <user name="$local"/> > <group alias="group_admin" name="${ldap_admin_grp}"/> > </include> > </role> > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2052) Bogus README.txt

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2052?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2052: ---------------------------------------- Assignee: (was: Jason Greene) > Bogus README.txt > ---------------- > > Key: WFCORE-2052 > URL: https://issues.jboss.org/browse/WFCORE-2052 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Brian Stansberry > > The README.txt file is wrong: > 1) It says WildFly 10. Wrong for core, and wrong #. > 2) Talks about javaee. > Probably this file should move to full and a simple variant for core should be written. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7714) Distributed web session expiration loads session twice

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7714: ---------------------------------- Summary: Distributed web session expiration loads session twice Key: WFLY-7714 URL: https://issues.jboss.org/browse/WFLY-7714 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7713) Distributed web session expiration loads session twice

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7713: ---------------------------------- Summary: Distributed web session expiration loads session twice Key: WFLY-7713 URL: https://issues.jboss.org/browse/WFLY-7713 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1677) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates opt-in as opposed to flooding reports with @Ignored tests

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1677?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFCORE-1677: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1938 (was: https://github.com/wildfly/wildfly-core/pull/1938, https://github.com/wildfly/wildfly/pull/9384) > Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates opt-in as opposed to flooding reports with @Ignored tests > ----------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1677 > URL: https://issues.jboss.org/browse/WFCORE-1677 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Affects Versions: 2.2.0.CR8 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 3.0.0.Alpha13 > > > It sounds to me that the test should really be validating the generated XML files, rather than the templates. > {noformat} > testSchemaOfSubsystemTemplates[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase) Time elapsed: 0.052 sec <<< FAILURE! > java.lang.AssertionError: error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected. > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.subsystem.test.SchemaValidator$1.error(SchemaValidator.java:73) > at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135) > at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394) > at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325) > at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282) > at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:481) > at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3571) > at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3508) > at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3434) > at org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3336) > at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2383) > at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:894) > at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:673) > at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645) > at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324) > at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875) > at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798) > at org.apache.xerces.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:186) > at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:129) > at javax.xml.validation.Validator.validate(Validator.java:124) > at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:123) > at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:101) > at org.jboss.as.subsystem.test.AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates(AbstractSubsystemBaseTest.java:144) > at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testSchemaOfSubsystemTemplates(SubsystemParsingTestCase.java:130) > Results : > Failed tests: > SubsystemParsingTestCase.testSchemaOfSubsystemTemplates:130->AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates:144 error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected. > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2071) Properly handle unknown roles instead of throwing exception

by Pedro Igor (JIRA)

Pedro Igor created WFCORE-2071: ---------------------------------- Summary: Properly handle unknown roles instead of throwing exception Key: WFCORE-2071 URL: https://issues.jboss.org/browse/WFCORE-2071 Project: WildFly Core Issue Type: Enhancement Components: Security Reporter: Pedro Igor Assignee: Darran Lofthouse When mapping roles directly from the identity: {code} <access-control provider="rbac" use-identity-roles="true"/> {code} If the identity has a role that is not known, a {{UnknowRoleException}} is thrown. Ideally, we should just ignore unknown roles. Or is there any reason for this check ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2016