This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 534850 - (RHQ-1606) Plugin autodiscovery should better support processes owned by other users [NEEDINFO]
Plugin autodiscovery should better support processes owned by other users
Status: NEW
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
unspecified
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
http://jira.rhq-project.org/browse/RH...
: FutureFeature, Improvement
Depends On:
Blocks: jon-sprint10-bugs
  Show dependency treegraph
 
Reported: 2009-02-18 17:35 EST by Charles Crouch
Modified: 2015-02-01 18:28 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
cwelton: needinfo? (ccrouch)


Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2009-02-18 17:35:00 EST
If the underlying OS lets a user determine information about processes other than the ones the user owns then Sigar should return that information too. The version of Sigar we shipped with JON 1.4.x (1.1.29) allowed for this but the one we currently use (1.5) does not (apparently its a security restriction which was introduced).

See Case 261296

[UPDATE 20100406: The above description is not accurate, Sigar is not restricting access to process information beyond that which the OS already restricts.

The enhancement here is to get our plugins to handle the case more gracefully of discovering processes which aren't run by the same user as the agent, e.g. apache running as root. Given the restrictions that the OS, Linux at least, places on information owned by other users, it may not be feasible to do exactly the same level of autodiscovery as we do currently, instead additional command line parameters may need to be specified (which can be read by other users) or possibly plugin configuration properties may need to be manually set after discovery has run and the resource has been imported.
Comment 1 John Mazzitelli 2009-02-18 17:45:29 EST
IMO - this is a silly and arbitrary "security" restriction that has no usefulness. What's the workaround? We'd have to do some cross-platform execution of the "ps" command to get the process information. If UNIX deems it not a security issue ("ps" can give you lots of information about other processes afterall) then we should not either.  We should get SIGAR to at least make this behavior configurable.
Comment 2 Red Hat Bugzilla 2009-11-10 15:36:37 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1606
Comment 3 wes hayutin 2010-02-16 12:10:08 EST
mass add of key word FutureFeature to help track
Comment 4 Charles Crouch 2010-04-01 19:08:53 EDT
(4:53:47 PM) ccrouch: so I just tried to reproduce
https://bugzilla.redhat.com/show_bug.cgi?id=534850 and found that a new user I
added via useradd can see all of the root processes
(4:57:13 PM) ccrouch: now there are couple of things you can't get 
(4:57:26 PM) ccrouch: the name of the executable and the cwd
(4:58:20 PM) ccrouch: but you can get the full commandline 
(5:00:20 PM) ips: crouch: yep, that's correct, you can see the basic process
info
(5:00:46 PM) ips: i think another thing you can't see as a different non-root
user is the process's environment
(5:01:22 PM) ips: you can run java -jar sigar.jar and run the various ps*
commands to see exactly what's restricted
(5:02:21 PM) ips: i don't think sigar is imposing restrictions beyong those
enforced by the OS as we originally thought
(5:02:50 PM) ips: you could verify that by cd'ing into /proc as that regular
user and seeing what you can access
(5:03:05 PM) ips: ie - for some other user's process
(5:03:13 PM) ips is now known as ips-dinner
(5:03:22 PM) ccrouch: ips-dinner: yep
(5:03:34 PM) ccrouch: i cant see the process's env
(5:03:47 PM) ccrouch: but do we really need that for basic discovery?
(5:04:08 PM) ips-dinner: we use it in a couple places  i know of
(5:04:18 PM) ips-dinner: PGDATA env var for Postgres
(5:04:38 PM) ips-dinner: to figure out the server's data dir in cases where
they didn't specify it via command line option
(5:05:31 PM) ips-dinner: and JAVA_HOME for JBoss procs to figure out what JVM
was used so we can set the javaHome conn prop, which is used by the start and
stopViaScript operations
(5:06:22 PM) ips-dinner: the java_home one's obviously not critical, but it's
nice to be able to autodetect the jvm and pre-set that conn prop
(5:07:01 PM) ccrouch: right, but we could always guess just using the path to
the java exe thats running the AS instance
(5:07:34 PM) ccrouch: i'm wondering if we could do a better job of gracefully
degrading in the case of stuff running as a different user
(5:09:45 PM) ccrouch: or at least say, if you start your jboss/apache instance
in the following way we'll be able to detect it, regardless of what user its
running as

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