Useradd segmentation fault [solved]

[kaizushi]

I am having an issue with the useradd command doing a segfault, I first asked about this problem on Libera IRC #gentoo and the person helped me talked me through gdb, and opening a bug ticket for shadow. I am copying the same information here because I am interested in a workaround. The system is a production shared webserver, and it's pretty hard to do what I need to do without having useradd working.

Kernel version: Linux 6.1.2
GCC version: Gentoo Hardened 12.2.1_p20221231 p8
Shadow version: 4.13-r1

I have tried the following...
* Rebuild util-linux, shadow, attr, pam.
* Try an older kernel version (because of the gdb output)
* Rebuilt the same packages above for the older Linux 6.0.19 kernel.

The gdb output...

Code: Select all

# gdb --args useradd -m -G users test1298
GNU gdb (Gentoo 12.1 vanilla) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from useradd...
Reading symbols from /usr/lib/debug//usr/sbin/useradd.debug...
(gdb) run
Starting program: /usr/sbin/useradd -m -G users test1298
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00006441cfa84319 in __sgr_dup (sgent=0x1000) at sgroupio.c:36
36      sgroupio.c: No such file or directory.
(gdb) bt
#0  0x00006441cfa84319 in __sgr_dup (sgent=0x1000) at sgroupio.c:36
#1  0x00006441cfa85c29 in commonio_open (db=db@entry=0x6441cfa92ca0 <gshadow_db>, mode=2, mode@entry=66)
    at commonio.c:694
#2  0x00006441cfa846ce in sgr_open (mode=mode@entry=66) at sgroupio.c:246
#3  0x00006441cfa7856e in open_group_files () at useradd.c:1856
#4  0x00006441cfa790fd in get_groups (list=0x7ffff616ef6d "users") at useradd.c:766
#5  process_flags (argc=argc@entry=5, argv=argv@entry=0x7ffff616ddb8) at useradd.c:1354
#6  0x00006441cfa73e46 in main (argc=5, argv=0x7ffff616ddb8) at useradd.c:2499
(gdb) p *sgent
Cannot access memory at address 0x1000

Help regarding some kind of workaround to get shadow working again would be highly appreciated. I am stuck in the water right now, until this is fixed.

[eccerr0r]

if you can simply just "useradd -m test1298" -- you can add the user into the groups you want manually after the fact?

[kaizushi]

if you can simply just "useradd -m test1298" -- you can add the user into the groups you want manually after the fact?

This also segfaults, here it is under gdb, it is the same issue as above...

Code: Select all

Starting program: /usr/sbin/useradd -m test1298
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00006544e8eb9319 in __sgr_dup (sgent=0x1000) at sgroupio.c:36
36      sgroupio.c: No such file or directory.
(gdb) bt
#0  0x00006544e8eb9319 in __sgr_dup (sgent=0x1000) at sgroupio.c:36
#1  0x00006544e8ebac29 in commonio_open (db=db@entry=0x6544e8ec7ca0 <gshadow_db>, mode=2, mode@entry=66)
    at commonio.c:694
#2  0x00006544e8eb96ce in sgr_open (mode=mode@entry=66) at sgroupio.c:246
#3  0x00006544e8ead56e in open_group_files () at useradd.c:1856
#4  0x00006544e8ea90df in open_files () at useradd.c:1797
#5  main (argc=<optimized out>, argv=<optimized out>) at useradd.c:2613
(gdb) p *sgent
Cannot access memory at address 0x1000

[kaizushi]

The good news is I just found a workaround, and I can use 'useradd' again after downgrading the shadow package to version sys-apps/shadow-4.12.3. I would have tried it sooner but I wanted a backup of my system, as downgrading things for me has gone wrong many times.

I would call this solved, as far as finding a workaround is concerned.

[eccerr0r]

Interesting. Yeah still needs to be fixed, I'm still at shadow 4.12.3 hence don't see this issue.

[Duncan Mac Leod]

Interesting. Yeah still needs to be fixed, I'm still at shadow 4.12.3 hence don't see this issue.

Hope the devs are keeping 4.12.3 in portage tree until this is fixed?

[pjp]

As i had already upgraded to sys-apps/shadow-4.13-r1 I've been keeping an eye on this. I don't see any responses in the bug report.

I tried the referenced usreadd command and it worked without errors.

[kaizushi]

It has been released in the bug ticket I opened on the Github that this bug occurs when there are really long lines in /etc/group, /etc/shadow, etc. This is why it happens for some and not others. The system where I was having this issue is a shared webserver and the line for group users is very long.

[eccerr0r]

Thanks for following up on this. Yeah it would be hard for me to reproduce, my group file lines are quite short.

[sam_]

I've been watching the libc-alpha thread and the github bug, but Hanno's filed a bug on the Gentoo side at bug 895784. We'll backport the fix once it's committed.

[kaizushi]

Can someone tell me how I can track this bug and the availability of the fix into Gentoo? This is very new territory for me.

[sam_]

Can someone tell me how I can track this bug and the availability of the fix into Gentoo? This is very new territory for me.

Add yourself to the CC list on the Gentoo bug I mentioned in the post above yours.