Bug 741289 - vhostmd doesn't set supplemental groups correctly.
Summary: vhostmd doesn't set supplemental groups correctly.
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vhostmd
Version: 6.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
Depends On:
Blocks: 989468
TreeView+ depends on / blocked
Reported: 2011-09-26 13:54 UTC by Richard W.M. Jones
Modified: 2013-07-29 10:24 UTC (History)
7 users (show)

Fixed In Version: vhostmd-0.4-2.6.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 989468 (view as bug list)
Last Closed: 2012-04-26 18:38:09 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0526 normal SHIPPED_LIVE vhostmd bug fix update 2012-04-26 22:28:37 UTC

Description Richard W.M. Jones 2011-09-26 13:54:21 UTC
Description of problem:

(reported by Steve Grubb)

vhostmd does not set supplemental groups correctly when it
changes (drops) privs.  Between setgid and setuid, there
should be a call to either initgroups or setgroups as appropriate.

Comment 1 Steve Grubb 2011-09-27 16:17:49 UTC
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"));

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.

Comment 3 Frank Danapfel 2011-12-12 09:21:52 UTC
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

Comment 4 Richard W.M. Jones 2011-12-12 09:38:13 UTC
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.

Comment 6 Richard W.M. Jones 2012-03-05 14:58:01 UTC
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

Comment 10 Mohua Li 2012-03-12 05:40:28 UTC
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

Comment 11 errata-xmlrpc 2012-04-26 18:38:09 UTC
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.


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