Ubuntu
shadow package

newgrp fails with "crypt: Invalid argument"

Bug #1355111 reported by Lorenz
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Shadow
Invalid
Undecided
shadow (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

entry from /etc/passwd:
user:x:1000:1000:User,,,:/home/user:/bin/bash

entry from /etc/group:
dummy:x:200:user

entry from /etc/gshadow:
dummy:*::

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: https://bugzilla.redhat.com/show_bug.cgi?id=988184

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"

Revision history for this message
In , Eric (eric-redhat-bugs) wrote :

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.

Revision history for this message
In , Eric (eric-redhat-bugs) wrote :

Oops, this is in the Debian Alioth tracker, not bugs.debian.org.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

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.

Revision history for this message
In , Eric (eric-redhat-bugs) wrote :

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.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Nope, there should not be a prompt in such situation and it isn't according to my testing.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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 https://wiki.ubuntu.com/Bugs/FindRightPackage. 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 https://bugs.launchpad.net/ubuntu/+bug/1355111/+editstatus 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)
affects: ubuntu → shadow (Ubuntu)
Revision history for this message
Lorenz (lqb) wrote :

This Bug affects saucy, too

Revision history for this message
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
comgrp:x:27:user1
#From NIS/LDAP or something similar
comgrp:x:27:user2
#From /etc/gshadow
comgrp:*::user3

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?

[src/newgrp.c]
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);

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in shadow (Ubuntu):
status: New → Confirmed
Revision history for this message
Marco Leichsenring (marco-leichsenring-ext) wrote :

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

Revision history for this message
Marco Leichsenring (marco-leichsenring-ext) wrote :

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.

Revision history for this message
Marco Leichsenring (marco-leichsenring-ext) wrote :

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

Marco

Marco Leichsenring (marco-leichsenring-ext)
tags: added: regression-release trusty
Revision history for this message
Sasa Paporovic (melchiaros) wrote :

Adding tag saucy regarding to reporter observation.

tags: added: saucy
Revision history for this message
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.

Revision history for this message
Henri Cook (henricook) wrote :

I can confirm this workaround worked for me on 15.10

Revision history for this message
Pamir Talazan (pamir-talazan) wrote :

The workaround also worked for me on 16.04

Bug Watch Updater (bug-watch-updater)
Changed in shadow:
importance: Unknown → Undecided
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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