Fix: getgrnam is not MT-Safe, use getgrnam_r
Running the test suite under a Yocto musl build resulted in musl
coredump due to double freeing.
We get the following backtraces:
0 a_crash () at ./arch/x86_64/atomic_arch.h:108
1 unmap_chunk (self=<optimized out>) at src/malloc/malloc.c:515
2 free (p=<optimized out>) at src/malloc/malloc.c:526
3 0x00007f46d9dc3849 in __getgrent_a (f=f@entry=0x7f46d9d1f7e0, gr=gr@entry=0x7f46d9e24460 <gr>, line=line@entry=0x7f46d9e26058 <line>, size=size@entry=0x7f46d92db550, mem=mem@entry=0x7f46d9e26050 <mem>, nmem=nmem@entry=0x7f46d92db558, res=0x7f46d92db548) at src/passwd/getgrent_a.c:45
4 0x00007f46d9dc2e6b in __getgr_a (name=0x487242 "tracing", gid=gid@entry=0, gr=gr@entry=0x7f46d9e24460 <gr>, buf=buf@entry=0x7f46d9e26058 <line>, size=size@entry=0x7f46d92db550, mem=mem@entry=0x7f46d9e26050 <mem>, nmem=0x7f46d92db558, res=0x7f46d92db548) at src/passwd/getgr_a.c:30
5 0x00007f46d9dc3733 in getgrnam (name=<optimized out>) at src/passwd/getgrent.c:37
6 0x0000000000460b29 in utils_get_group_id (name=<optimized out>) at ../../../lttng-tools-2.10.6/src/common/utils.c:1241
7 0x000000000044ee69 in thread_manage_health (data=<optimized out>) at ../../../../lttng-tools-2.10.6/src/bin/lttng-sessiond/main.c:4115
8 0x00007f46d9de1541 in start (p=<optimized out>) at src/thread/pthread_create.c:195
9 0x00007f46d9dee661 in __clone () at src/thread/x86_64/clone.s:22
From another run:
0 a_crash () at ./arch/x86_64/atomic_arch.h:108
1 unmap_chunk (self=<optimized out>) at src/malloc/malloc.c:515
2 free (p=<optimized out>) at src/malloc/malloc.c:526
3 0x00007f5abc210849 in __getgrent_a (f=f@entry=0x7f5abc2733e0, gr=gr@entry=0x7f5abc271460 <gr>, line=line@entry=0x7f5abc273058 <line>, size=size@entry=0x7f5abaef5510, mem=mem@entry=0x7f5abc273050 <mem>, nmem=nmem@entry=0x7f5abaef5518, res=0x7f5abaef5508) at src/passwd/getgrent_a.c:45
4 0x00007f5abc20fe6b in __getgr_a (name=0x487242 "tracing", gid=gid@entry=0, gr=gr@entry=0x7f5abc271460 <gr>, buf=buf@entry=0x7f5abc273058 <line>, size=size@entry=0x7f5abaef5510, mem=mem@entry=0x7f5abc273050 <mem>, nmem=0x7f5abaef5518, res=0x7f5abaef5508) at src/passwd/getgr_a.c:30
5 0x00007f5abc210733 in getgrnam (name=<optimized out>) at src/passwd/getgrent.c:37
6 0x0000000000460b29 in utils_get_group_id (name=<optimized out>) at ../../../lttng-tools-2.10.6/src/common/utils.c:1241
7 0x000000000042dee4 in notification_channel_socket_create () at ../../../../lttng-tools-2.10.6/src/bin/lttng-sessiond/notification-thread.c:238
8 init_thread_state (state=0x7f5abaef5560, handle=0x7f5abbf9be40) at ../../../../lttng-tools-2.10.6/src/bin/lttng-sessiond/notification-thread.c:375
9 thread_notification (data=0x7f5abbf9be40) at ../../../../lttng-tools-2.10.6/src/bin/lttng-sessiond/notification-thread.c:495
10 0x00007f5abc22e541 in start (p=<optimized out>) at src/thread/pthread_create.c:195
11 0x00007f5abc23b661 in __clone () at src/thread/x86_64/clone.s:22
The problem was easily reproducible (~6 crash on ~300 runs). A prototype fix
using mutex around the getgrnam yielded no crash in over 1000 runs. This
patch yielded the same results as the prototype fix.
Unfortunately we cannot rely on a mutex in liblttng-ctl since we cannot
enforce the locking for the application using the lib.
Use getgrnam_r instead.
The previous implementation of utils_get_group_id returned the gid of
the root group (0) on error/not found. lttng_check_tracing_group needs
to know if an error/not found occured, returning the root group is not
enough. We now return the gid via the passed parameter. The caller is
responsible for either defaulting to the root group or propagating the
error.
We also do not want to warn when used in liblttng-ctl context. We might
want to move the warning elsewhere in the future. For now, pass a bool
if we need to warn or not.
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
This page took 0.026887 seconds and 4 git commands to generate.