Red Hat Bugzilla – Bug 534850
Plugin autodiscovery should better support processes owned by other users
Last modified: 2015-02-01 18:28:44 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.
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.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1606
mass add of key word FutureFeature to help track
(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