Bug 1016049 - INFO message exception stack trace filling server.log file
INFO message exception stack trace filling server.log file
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
4.9
Unspecified Unspecified
unspecified Severity low (vote)
: ---
: RHQ 4.10
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On: 1012449
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-07 08:03 EDT by Heiko W. Rupp
Modified: 2014-04-23 08:30 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1012449
Environment:
Last Closed: 2014-04-23 08:30:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Heiko W. Rupp 2013-10-07 08:03:33 EDT
+++ This bug was initially created as a clone of Bug #1012449 +++

Description of problem:
I created a role with default permissions + Manage Alert (Write). Assigned a user on that group. logged-in via that user. When ever I clock "Inventory", INFO message filling the server.log file with stack exception trace(attached).

00:27:39,683 INFO  [org.rhq.enterprise.server.resource.ResourceManagerBean] (http-/0.0.0.0:7080-4) Failed to get live availability.: org.rhq.enterprise.server.authz.PermissionException: Can not get agent details - Subject[id=10001,name=testuser] lacks MANAGE_SETTINGS for resource[id=10001]

I feel as this is an expected message, we might put it on DEBUG level and may remove exception stack trace.

Version-Release number of selected component (if applicable):
Version: 3.2.0.ER1
Build Number: 54dd29c:464a643
GWT Version: 2.5.0
SmartGWT Version: 3.0

How reproducible:
100%

Steps to Reproduce:
1. create a role with default permissions + Manage Alert (Write).
2. create an user and assign the user to the role (step#1) 
3. login via the user created on step#2
4. tail server.log
5. Click on "Inventory" tab.


Additional info: log is attached

--- Additional comment from Heiko W. Rupp on 2013-10-07 08:00:51 EDT ---

master e0283c2

Please note, that in above case when the user e.g. only has access to a group with CPUs, but not to the platform itself, which is what

  >>>  PermissionException: Can not get agent details -  
  >>> Subject[id=10001,name=testuser] lacks MANAGE_SETTINGS for resource[id=10001]

is saying, it also means that the interactive avail check in the UI is failing (as it can not be triggered), so that availability shows grey.

I am marking this one as modified, as this issue is solved, but will clone it to consider changing the handling here.
Comment 1 Lukas Krejci 2013-10-07 09:00:42 EDT
commit 8356e9344fa5c768607eb1b341c4ece550319694
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Mon Oct 7 14:49:14 2013 +0200

    [BZ 1016049] - Avoid requiring MANAGE_SETTINGS for live avail checks.
    
    We were using a method that requires MANAGE_SETTINGS permission, which
    is not what we want here. If a user has perms to view a resource (which
    is checked for), they should be able to access its availability.
Comment 2 Lukas Krejci 2013-10-09 08:11:14 EDT
commit 83330253f038abaad9311a376257700197a0ffa4
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Wed Oct 9 14:08:30 2013 +0200

    [BZ 1016049] - Avoid requiring MANAGE_SETTINGS for live avail checks.
    
    trying to use AgentManagerLocal.getAgentClient(Agent) does not work in
    ResourceManagerBean.getLiveAvailability() because getLiveAvailability()
    never runs in a transaction.
    
    Use the original approach taken by BZ 988881, only making sure we pass in
    an overlord when requesting the agent client to avoid the failing perm
    check if the user requesting the live availability doesn't have
    MANAGE_SETTINGS permission.
Comment 3 Heiko W. Rupp 2014-04-23 08:30:49 EDT
Bulk closing of 4.10 issues.

If an issue is not solved for you, please open a new BZ (or clone the existing one) with a version designator of 4.10.

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