newgrp fails with "crypt: Invalid argument"

Bug #1355111 reported by Lorenz on 2014-08-11
This bug affects 6 people
Affects Status Importance Assigned to Milestone
shadow (Ubuntu)

Bug Description

entry from /etc/passwd:

entry from /etc/group:

entry from /etc/gshadow:

logged on as user the command
"newgrp dummy" asks for a password and fails with "crypt: Invalid argument"

after removing the line for dummy from gshadow newgrp works

A similar bug was reported on the redhat tracker:

cat /etc/lsb-release

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.

Oops, this is in the Debian Alioth tracker, not

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.

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Lorenz (lqb) on 2014-08-12
affects: ubuntu → shadow (Ubuntu)
Lorenz (lqb) wrote :

This Bug affects saucy, too

Lorenz (lqb) wrote :

I had a look in src/newgrp.c
I wonder why the variable grp is overwritten several times, before check_perms is called.
In my understanding, this means the last found group entry wins.

If I have following group entries in my environment:
#From /etc/passwd
#From NIS/LDAP or something similar
#From /etc/gshadow

user1 and user2 aren't able to change primary group to comgrp because check_perms only sees user3 in that group.
I had expected that all three users are able to change to the comgrp.
What is the correct behaviour? And why?

617 grp = getgrnam (group); /* local, no need for xgetgrnam */
628 grp = find_matching_group (name, grp->gr_gid);
637 grp = xgetgrnam (group);
644 grp->gr_mem = sgrp->sg_mem;
651 check_perms (grp, pwd, group);

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in shadow (Ubuntu):
status: New → Confirmed

I confirm this bug. Will there be an update as it already has been on Debian in the shadow-utils package?

perhaps an strace might help...the group I want to have as primary group is called DummyGroup here and is part of an active directory infrastructure. In 12.04 everything worked and I was able to change to that group.

To make it more clearly, I have attached another logfile. This new one is from Ubuntu 12.04 in the same environment as above.

If you diff it with the stracenewgrp.log you can see, that in Ubuntu 14.04 the newgrp tries to allocate files associated to the language settings in /usr/share/locale while this is not the behaviour in 12.04. For what are those files located in the locales needed? The files it tries to access are not installed nor can they be installed as far as I know (please correct me if I am wrong here). It seems to me that it uses these files for the whole group handling which does not make sense at all to me. The /etc/login.defs does make a lot more sense...

Hope this helps.

Kind regards


tags: added: regression-release trusty
Sasa Paporovic (melchiaros) wrote :

Adding tag saucy regarding to reporter observation.

tags: added: saucy
David Kedves (kedazo) wrote :

I was getting this issue on ubuntu 15.04 (Vivid Vervet) too...
However I've found a workaround, running 'grpconv' as root fixed the problem for me.

Henri Cook (henricook) wrote :

I can confirm this workaround worked for me on 15.10

Pamir Talazan (pamir-talazan) wrote :

The workaround also worked for me on 16.04

Changed in shadow:
importance: Unknown → Undecided
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.