Red Hat Bugzilla – Bug 988188
newgrp fails with "setgroups: Operation not permitted"
Last modified: 2013-07-25 11:58:23 EDT
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):
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.
setgroups: Operation not permitted
setgid: Operation not permitted
user gets a subshell with the group in the group list (as shown by the "id" command)
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.