Util-linux's login program does something like this:

    if (initgroups(user, pwd->pw_gid) < 0) {
            syslog(LOG_ERR, "initgroups: %m");
            fprintf(stderr, _("\nSession setup problem, abort.\n"));
            exit(1);
    }

This can be adapted to vhostmd.c. The problem is that supplemental groups from the root account can be leaked into daemons unless they specifically clear the supplemental groups.

To test this, go into a system as root. Use the id program to verify root has some supplemental groups. Restart vhostmd. Get its pid. Look in /proc/<pid>/status for the "Groups" line. You should see some leaked groups. 

When patched, you should not.

Hi Lei, SAP normally does not perform any testing on the vhostmd package for bugs not found by themselves. I could run some tests with an updated version of the package, but since the test rooutine I use is very simple it should be possible to integrate it in the regular QA for this package:

- install vhostmd on the host and verify that it starts correctly and runs with the correct permissions and the right user and groups
- wait a few minutes and then do a "cat /dev/shm/vhostmd0"; this should return an XML file showing the metrics of the host and the guest running on it; repeat this a few times and compare the results to verify that the values get updated
- attach /dev/shm/vhostmd0 as a CDROM device to a guest running on the same host and install vm-dump-metrics on the guest
- run vm-dump-metrics inside the guest to verify that it is able to read the data; the result should be an XML file that looks similar to the one you get when running "cat /dev/shm/vhostmd0" on the host

I'll provide some way for QA to verify this bug (in a future
comment here), once I've fixed it.  It will probably involve
just starting up vhostmd and using ps tools or /proc to verify
what groups it belongs to before and after the change.

The test is simple.  After starting vhostmd, run the
following command:

$ grep ^Groups: /proc/`pidof vhostmd`/status

If the bug is fixed, you should see one group, which is the
group of vhostmd (112 on Fedora, not sure about RHEL, but you
can check in /etc/group for the right number).  eg:

$ grep ^Groups: /proc/`pidof vhostmd`/status
Groups:	112 

However if you see a list of groups here, then there is an error.
For example, on Fedora with the unfixed vhostmd you see:

$ grep ^Groups: /proc/`pidof vhostmd`/status
Groups:	0 1 2 3 4 6 10 

This is very bad because (eg) '0' is the group of the root
account.

Upstream fix:
https://gitorious.org/vhostmd/vhostmd/commit/8684995d87e08fadd44e1814e810c770a1f60273

pls ignore comment 9, vhostmd restart fail due to some reason on my env, still debugging,  re-check the result should pass, 

[lmh@dhcp-93-131 ~]$ grep ^Groups /proc/$(pidof vhostmd)/status
Groups: 112

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0526.html