Description of problem: I upgrade a F-15 test installation to F-16 beta, and ran a yum update as root. Then I tried, as a normal user, a sudo command and was informed that I was not in the sudoers file. In the F-15 installation, I had set myself into the wheel group and edited sudoers to give all wheel group members sudo ALL privileges. When I checked the system-config-users setting, I was shown to be a member of the wheel group, and when I ran the command "newgrp wheel," I was listed (with now "Password" prompt) as a member of the wheel group by the "groups" command. And the "sudo" then worked for me. Now I don't really know if system-config-user is the problem, but I thought you'd like to know that group membership (except for the basic user-group = user-name) is somehow lost when one upgrades, and that the settings that are know to system-config-user are ignored for actual group membership. (And, to reiterate, are lost after a reboot, even if they have been set by the newgrp command to one of the listed groups.) Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. Use system-config-user to add group membership to a user. 2. Use the groups command to confirm that the membership is not active 3. Reboot, and verify that the membership is still not active Actual results: Not a member of the specified group(s) Expected results: Membership in the specified groups. Additional info: From a terminal window (note the lack of complaint for "wheel": $ groups Peter $ newgrp wheel $ groups wheel Peter $ newgrp root Password: Invalid password. $ groups wheel Peter
This is most likely a glibc issue (bug #745675) which makes users only belong to their primary group (but not any additional ones, like wheel). NB: the newgrp command doesn't permanently set group memberships, only temporarily, like e.g. the "su" command does for switching user ids. *** This bug has been marked as a duplicate of bug 745675 ***