useradd doesn't add the default shell to /etc/passwd entry

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

This problem is introduced by debian/patches/1000_configure_userns.
I sent merge request, could you review it?

Thanks, the patch looks good to me.

This is still the case with latest installed package of passwd (where I found useradd):

ii passwd 1:4.1.5.1-1ubuntu9 amd64 change and administer password and group data

Could this be a sign of useradd ignoring everything in /etc/default/useradd? I've stumbled upon a problem when changing the default HOME base directory. Example:

# useradd -D
GROUP=100
HOME=/tmp
INACTIVE=-1
EXPIRE=
SHELL=/bin/sh
SKEL=/etc/skel
CREATE_MAIL_SPOOL=no
# useradd -m testuser14
# grep testuser14 /etc/passwd
testuser14:x:5012:5012::/home/testuser14:

I think useradd is not only ignoring the SHELL variable (though I didn't change it in this example), but also the rest of variables that appear in /etc/default/useradd.

I found a possible culprit. Patch debian/patches/1000_configure_userns swaps the order of `get_defaults`* and `process_flags`, but it's the job of `process_flags` to read the defaults if they weren't overridden on the command line. For instance, `process_flags` contains

```
        if (!gflg) {
                user_gid = def_group;
        }

        if (!sflg) {
                user_shell = def_shell;
        }
```

In fact, `process_flags` will end up doing that, but with the compiled-in defaults. I'm not 100% sure I understand the patched code, but ***maybe*** the fix is as simple as restoring the order of instructions, including of `is_sub_gid`; but I haven't read the logic for `is_sub_gid`.

Here's the guilty patch fragment (not applicable):
```
--- shadow.orig/src/useradd.c 2014-02-16 19:31:38.934898148 -0500
+++ shadow/src/useradd.c 2014-02-16 19:31:38.926898149 -0500
[...]
-
- get_defaults ();

        process_flags (argc, argv);

+ is_sub_uid = sub_uid_file_present () && !rflg &&
+ (!user_id || (user_id <= uid_max && user_id >= uid_min));
+ is_sub_gid = sub_gid_file_present () && !rflg &&
+ (!user_id || (user_id <= uid_max && user_id >= uid_min));
+
+ get_defaults ();
+
```

*I'm using Markdown syntax to distinguish code and text.

Sorry, I shouldn't have made the previous comment — I had just looked at the last comment. Now I looked at the rest of the code, and discovered that you have already a fix, you just didn't apply it to trusty. Would you please do so?

Roberto (#7), you are correct, but IIUC that *is* addressed by the patch for utopic.

It seems that the fix is still not applied. Is there a reason why?
The bug makes it quite annoying to use Ansible or the like.

regards
 christian

I just ran into the same problem on Ubuntu 16.04:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial
$ cat /etc/default/useradd
SHELL=/bin/bash
$ useradd -D
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=no
$ sudo useradd testuser
$ getent passwd testuser
testuser:x:1081:1082::/home/testuser:

I expected testuser to show /bin/bash for the shell, but that's not the case.

I can confirm this is still happening on 16.04. The whole file is ignored.

Tested this in eoan. New user got the SHELL=zsh which I specified in /etc/default/useradd