|Summary:||Make sure that all the SLSB methods are callable from scripted alert notifications|
|Product:||[JBoss] JBoss Operations Network||Reporter:||Lukas Krejci <lkrejci>|
|Component:||Core Server||Assignee:||RHQ Project Maintainer <rhq-maint>|
|Status:||CLOSED UPSTREAM||QA Contact:||Mike Foley <mfoley>|
|Target Release:||JON 3.2.0|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-11-19 14:30:05 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||967675|
Description Lukas Krejci 2013-05-28 00:36:27 UTC
Description of problem: EAP 6.1 that JON uses as the base container implements some additional java security permission checks not present in AS 7.1.1.Final (for example the ModelController.createClient() method). We need to make sure that any such hardened methods reachable from our remote API and classes accessible to the CLI alert scripts are properly handled. This means that we either let the security exception propagate if we determine that such usage by scripts is indeed dangerous or we need to surround such calls in privileged action blocks so that they're usable from the scripts. Version-Release number of selected component (if applicable): JON 3.2.0 How reproducible: maybe, one instance of this already captured by BZ 967622 Additional Notes: This is meant to be an umbrella BZ that should depend on concrete cases.
Comment 1 Heiko W. Rupp 2013-09-09 07:35:41 UTC
Lukas can you please investigate this and also the dependent Bug 967675 what there is to do.
Comment 2 Lukas Krejci 2013-10-14 13:27:09 UTC
IMHO, we shouldn't be too worried about this, because we haven't had any new instance of such security-related problems since bug 967622 (or its JON equivalent, BZ 967675). I believe the QA coverage of the APIs is rather good so I assume we'd already have seen this kind of problems (as we did with BZ 967622 that was discovered by QE). I propose to close this. What do you think, Heiko?
Comment 3 Heiko W. Rupp 2013-10-16 09:40:17 UTC
I am in favor of closing if we haven't found new instances of this in the investigations.
Comment 4 Lukas Krejci 2013-11-19 14:30:05 UTC
Closing. We haven't discovered a new issue similar to this for the last 10 months.