Bug 988184
| Summary: | newgrp fails with "crypt: Invalid argument" when correct password given | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eric Smith <spacewar> |
| Component: | shadow-utils | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | pvrabec, tmraz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-18 14:18:28 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Oops, this is in the Debian Alioth tracker, not bugs.debian.org. 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. 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. Nope, there should not be a prompt in such situation and it isn't according to my testing. |
Description of problem: newgrp fails with "crypt: Invalid argument" even when the correct password is given Version-Release number of selected component (if applicable): shadow-utils-4.1.5.1-5.fc19 glibc-2.17.11.fc19 How reproducible: 100% 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: https://alioth.debian.org/tracker/index.php?func=detail&aid=314234 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.