I see this too.
(gdb) run
Starting program: /tmp/shadow-4.1.5/src/userdel localtest
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff787a0f8 in _IO_vfprintf_internal (s=0x55555557a1d0,
format=0x555555562748 "removed shadow group '%s' owned by '%s'\n",
ap=0x7fffffffe330) at vfprintf.c:1620
1620 vfprintf.c: No such file or directory.
in vfprintf.c
(gdb) where
#0 0x00007ffff787a0f8 in _IO_vfprintf_internal (s=0x55555557a1d0,
format=0x555555562748 "removed shadow group '%s' owned by '%s'\n",
ap=0x7fffffffe330) at vfprintf.c:1620
#1 0x00007ffff790ae90 in *__GI___vsyslog_chk (pri=<optimized out>,
flag=-1, fmt=<optimized out>, ap=0x7fffffffe330) at ../misc/syslog.c:222
#2 0x00007ffff790b0c0 in __syslog (pri=4542553, fmt=0x18 <Address 0x18
out of bounds>) at ../misc/syslog.c:119
#3 0x0000555555558215 in remove_usergroup () at userdel.c:367
#4 0x0000555555557c56 in update_groups () at userdel.c:213
#5 0x0000555555559b41 in main (argc=2, argv=0x7fffffffe628) at
userdel.c:1040
(gdb) frame 3
#3 0x0000555555558215 in remove_usergroup () at userdel.c:367
367 SYSLOG ((LOG_INFO,
(gdb) l
362 audit_logger (AUDIT_DEL_GROUP, Prog,
363 "deleting shadow group",
364 grp->gr_name, AUDIT_NO_ID,
365 SHADOW_AUDIT_SUCCESS);
366 #endif /* WITH_AUDIT */
367 SYSLOG ((LOG_INFO,
368 "removed shadow group '%s'
owned by '%s'\n",
369 grp->gr_name, user_name));
370
371 }
(gdb) p grp
$1 = (const struct group *) 0x55555557a110
(gdb) p grp->gr_name
$2 = 0x4300455059 <Address 0x4300455059 out of bounds>
(gdb) p user_name
$3 = 0x7fffffffe88c "localtest"
During this run the following messages went to syslog:
Feb 23 16:28:07 leela userdel[39752]: delete user 'localtest'
Feb 23 16:28:07 leela userdel[39752]: removed group '(null)' owned by
'localtest'
There's something funny going on...
Breakpoint 1 at 0x555555557eaa: file userdel.c, line 288.
...
336 if (gr_remove (grp->gr_name) == 0) {
(gdb) p grp->gr_name
$6 = 0x55555557a140 "localtest"
(gdb) n
349 SYSLOG ((LOG_INFO,
(gdb) p grp->gr_name
$7 = 0x0
I assume grp->gr_name is *not* meant to be 0 here; otherwise the log
messages that reference it are invoking UB. But even though gr_remove
returns 1, the group is still on the system.
--
Sam Morris <s...@robots.org.uk>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
