Description of problem: When executed by an unprivileged user, newgrp fails with "setgroups: Operation not permitted" and "setgid: Operation not permitted". Version-Release number of selected component (if applicable): shadow-utils-4.1.5.1-5.fc19 How reproducible: 100% Steps to Reproduce: 0. Apply the patch to shadow-utils for bug #988184, which masks this problem. 1. Create a new group without a password, or use an existing group that doesn't have a password. I happened to discover this using the "mock" group. 2. Add a already logged-in user to a group in /etc/group. 3. Note that the current user login session is not a member of that group, i.e., by using the "id" command at a shell prompt 4. Issue a "newgrp <groupname>" command. 5. When prompted, enter the user's password. Actual results: setgroups: Operation not permitted setgid: Operation not permitted Expected results: user gets a subshell with the group in the group list (as shown by the "id" command) Additional info: This happens because /usr/bin/newgrp is not installed setuid. The man page describes usage for newgrp by non-root users to add a group to the groupset, but this requires that it be installed setuid. Is installing it without setuid a deliberate decision? I've used newgrp this way as a non-root user in earlier Fedora release, though perhaps not recently.
It does not seem to be a bug in the shadow-utils package - note that the newgrp in the package is actually setuid. So there must be some problem with your installation?
You're right. When I rebuilt the shadow-utils RPM locally with the crypt patch (bug #988184), it built with /usr/sbin/newgrp not setuid. The official package does have it.