Bug 988184 - newgrp fails with "crypt: Invalid argument" when correct password given
newgrp fails with "crypt: Invalid argument" when correct password given
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-07-24 22:56 EDT by Eric Smith
Modified: 2013-10-18 10:18 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-18 10:18:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eric Smith 2013-07-24 22:56:36 EDT
Description of problem:
newgrp fails with "crypt: Invalid argument" even when the correct password is given

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
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:
crypt: Invalid argument

Expected results:
user gets a subshell with the group in the group list (as shown by the "id" command)

Additional info:
This is due to a change in behavior in crypt() in glibc 2.17.  It has been reported upstream along with a patch that fixes it:
I have locally rebuilt the RPM with that patch added, and it solves the crypt problem.  The patch applied cleanly with -p1.

Note that with the crypt problem solved, newgrp then gives different errors:
    setgroups: Operation not permitted
    setgid: Operation not permitted
However, that is a completely independent bug or configuration error that I am still investigating.
Comment 1 Eric Smith 2013-07-24 22:58:20 EDT
Oops, this is in the Debian Alioth tracker, not bugs.debian.org.
Comment 2 Tomas Mraz 2013-07-25 08:12:38 EDT
It is really weird how you could get this error. If the user is member of the group, he will never be prompted for a password when newgrp groupname is issued. And when he is not and there is no password in group/gshadow set this bug will just affect the message issued. Though applying the patch is correct thing as crypt: Invalid argument is not a particularly good message.
Comment 3 Eric Smith 2013-07-25 11:46:54 EDT
The case is that the user was not a member of the group at login, but was added to /etc/group after login, then using newgrp to get a subshell with that group added. Doesn't the user get prompted for their own password in that case?  I think I last experienced this use case with F14, and I don't remember whether I was prompted for a password or not.  I might fire up F14 in a VM to check.
Comment 4 Tomas Mraz 2013-07-25 14:27:59 EDT
Nope, there should not be a prompt in such situation and it isn't according to my testing.

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