Bug 790030 - trying to call ProxyFactory methods inside CLI alert scripts throws AccessControlExceptions
Summary: trying to call ProxyFactory methods inside CLI alert scripts throws AccessCon...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Core Server
Version: 4.3
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: JON 3.0.1
Assignee: Lukas Krejci
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On: 786106
Blocks: jon310-sprint11, rhq44-sprint11 786172
TreeView+ depends on / blocked
 
Reported: 2012-02-13 14:18 UTC by Lukas Krejci
Modified: 2013-09-03 15:14 UTC (History)
3 users (show)

Fixed In Version:
Clone Of: 786106
Environment:
Last Closed: 2013-09-03 15:14:52 UTC
Embargoed:


Attachments (Terms of Use)

Description Lukas Krejci 2012-02-13 14:18:08 UTC
+++ This bug was initially created as a clone of Bug #786106 +++

Description of problem:
$SUBJECT

Version-Release number of selected component (if applicable):
4.3.0-SNAPSHOT

How reproducible:
always

Steps to Reproduce:
1. Create CLI script that uses ProxyFactory to obtain some resource (ProxyFactory.getResource(10001)), create alert, attach the script as one of its notifications.
2. Let the alert fire
  
Actual results:
In the alert history, review the cli notification results - it shows an access control exception

Expected results:
No access control exception should have been thrown

Additional info:

--- Additional comment from lkrejci on 2012-01-31 08:38:48 EST ---

commit http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=02dafbc97a76c3813afd0f05b213d8a1de70a3c2
Author: Lukas Krejci <lkrejci>
Date:   Tue Jan 31 14:35:07 2012 +0100

    [BZ 786106] Wrap calls to obtain managers in privileged blocks so that 3rd
    callers can safely obtain them.
    
    The StandardBindings put all the managers into the script context before
    the script engine is initialized with the security measures which makes
    the managers available inside the scripts. Java code that gets injected as
    other params into the scripts (like the "ProxyFactory" (of class
    ResourceClientFactory) would suffer from access control exceptions when
    it tried to obtain some manager while being called from the script because
    it would try to call the methods from the LocalClient to obtain the remote
    interfaces directly, without a wrapping in a privileged block). Obtaining
    the remote interfaces is a safe operation wrt the scripts and so can be
    wrapped in privileged block so that any caller of the LocalClient can
    have access to the regardless of the access control restrictions in place.

--- Additional comment from mfoley on 2012-02-02 14:01:06 EST ---

created alert ... with CLI script as described in the description.  alert fired many times.  did not see access control exceptions in the server log.

--- Additional comment from lkrejci on 2012-02-13 09:16:47 EST ---

Making this BZ block the correct tracker.

Comment 2 Mike Foley 2012-02-13 14:45:10 UTC
QE ... this should be verifiable in RC5

Comment 3 Mike Foley 2012-02-13 16:59:34 UTC
per triage 2/13/2012 (asantos, crouch, foley, loleary)

Comment 4 Simeon Pinder 2012-02-17 05:36:16 UTC
Moving to ON_QA for testing with JON 3.0.1.GA RC5 or better:
https://brewweb.devel.redhat.com//buildinfo?buildID=199114

Comment 5 Mike Foley 2012-02-21 15:49:27 UTC
verified JON 3.01 RC5 as follows:

1) created a drift definition  
2) created an alert based on drift detection.  this alert's notification is a CLI script as defined above, eg ProxyFactory.getResource(10001)
3) created drift, which triggered the alert
4) reviewed alert history to make sure the alert fired
5) reviewed server log to make sure access control exception was not fired.

Comment 6 Lukas Krejci 2012-02-21 16:08:43 UTC
The access control exception would have appeared as the part of the output of the notification. Go to the details of the alert in the history page and review its notifications tab.

The exception might also bubble up to the server log, but I am currently not looking at the code and don't remember for sure from top of my head.

Comment 7 Mike Foley 2012-02-21 20:54:19 UTC
performed additional verification per comment #6.

Comment 8 Heiko W. Rupp 2013-09-03 15:14:52 UTC
Bulk closing of old issues in VERIFIED state.


Note You need to log in before you can comment on or make changes to this bug.