On 2017-11-28 03:36, Seth Arnold wrote:
Can sysdig grab stacktraces at the time of the open() call? It might be
educational to find out what exactly is doing the reading.
After installing `libglib2.0-0-dbgsym` package from `unstable-debug`
repository, I get these backtraces:
```
Thread 91 "pool" hit Breakpoint 1, 0x7f833be2c9d0 in open64 () from
/lib/x86_64-linux-gnu/libpthread.so.0
$650 = 0x7f8302a0bb20 "/home/vincas/.vimrc"
#0 0x7f833be2c9d0 in open64 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x7f8334d3f526 in open (__oflag=262144, __path=0x7f8302a0bb20 "/home/vincas/.vimrc") at
/usr/include/x86_64-linux-gnu/bits/fcntl2.h:53
#2 get_content_type (basename=0x7f831078f120 ".vimrc", path=0x7f8302a0bb20 "/home/vincas/.vimrc", statbuf=out>, fast=0, flags=,
symlink_broken=, is_symlink=) at
../../../../gio/glocalfileinfo.c:1284
#3 0x7f8334d40fe9 in _g_local_file_info_get (basename=basename@entry=0x7f831078f120 ".vimrc",
path=path@entry=0x7f8302a0bb20 "/home/vincas/.vimrc",
attribute_matcher=, flags=G_FILE_QUERY_INFO_NONE, parent_info=0x7f82fe2290c8,
error=error@entry=0x7f8316bfddf0) at ../../../../gio/glocalfileinfo.c:1870
#4 0x7f8334d3e42b in g_local_file_enumerator_next_file (enumerator=0x7f82fe229080, cancellable=,
error=0x7f8316bfde50)
at ../../../../gio/glocalfileenumerator.c:407
#5 0x7f8334cb0930 in next_files_thread (task=0x7f82fe5b2420, source_object=0x7f82fe229080, task_data=out>, cancellable=0x7f8305a504a0)
at ../../../../gio/gfileenumerator.c:769
#6 0x7f8334ce8cf6 in g_task_thread_pool_thread (thread_data=0x7f82fe5b2420, pool_data=) at
../../../../gio/gtask.c:1328
#7 0x7f8334768000 in g_thread_pool_thread_proxy (data=) at
../../../../glib/gthreadpool.c:307
#8 0x7f8334767635 in g_thread_proxy (data=0x7f830608edd0) at
../../../../glib/gthread.c:784
#9 0x7f833be22519 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#10 0x7f833b0b7a5f in clone () from /lib/x86_64-linux-gnu/libc.so.6
```
```
Thread 93 "pool" hit Breakpoint 1, 0x7f833be2c9d0 in open64 () from
/lib/x86_64-linux-gnu/libpthread.so.0
$1422 = 0x7f8302a66d20 "/home/vincas/.vimrc"
#0 0x7f833be2c9d0 in open64 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x7f8334d3f526 in open (__oflag=262144, __path=0x7f8302a66d20 "/home/vincas/.vimrc") at
/usr/include/x86_64-linux-gnu/bits/fcntl2.h:53
#2 get_content_type (basename=0x7f8315fab290 ".vimrc", path=0x7f8302a66d20 "/home/vincas/.vimrc", statbuf=out>, fast=0, flags=,
symlink_broken=, is_symlink=) at
../../../../gio/glocalfileinfo.c:1284
#3 0x7f8334d40fe9 in _g_local_file_info_get (basename=basename@entry=0x7f8315fab290 ".vimrc", path=0x7f8302a66d20
"/home/vincas/.vimrc",
attribute_matcher=attribute_matcher@entry=0x7f8302a78820, flags=flags@entry=G_FILE_QUERY_INFO_NONE,
parent_info=parent_info@entry=0x7f82ea9c5e10,
error=error@entry=0x7f82ea9c5e80) at ../../../../gio/glocalfileinfo.c:1870
#4 0x7f8334d3bab7 in g_local_file_query_info (file=0x7f8302a66cc0, attributes=,
flags=G_FILE_QUERY_INFO_NONE, cancellable=,
error=0x7f82ea9c5e80) at ../../../../gio/glocalfile.c:1275
#5 0x7f8334ca8014 in query_info_async_thread (task=0x7f82fe5b3390, object=, task_data=out>, cancellable=)
at ../../../../gio/gfile.c:5397
#6 0x7f8334ce8cf6 in g_task_thread_pool_thread (thread_data=0x7f82fe5b3390, pool_data=) at
../../../../gio/gtask.c:1328
#7 0x7f8334768000 in g_thread_pool_thread_proxy (data=) at
../../../../glib/gthreadpool.c:307
#8 0x7f8334767635 in g_thread_proxy (data=0x7f8309cc6ce0) at
../../../../glib/gthread.c:784
#9 0x7f833be22519 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#10 0x7f833b0b7a5f in clone () from /lib/x86_64-linux-gnu/libc.so.6
```
So the first one is g_local_file_enumerator_next_file() [0] calling get_content_type() [1] which probably calls
g_content_type_guess() [2] which involves MIME stuff.
Second backtrace also goes into same get_content_type(), but initiated by g_local_file_query_info(). It seems like a
duplication but that's out of this discussion scope anyhow.
Anyway, maybe it would be possible to apply a hat to these async glib helper threads, allowing the to read anything? Can
AppArmor hat be applied for a thread only? This implies that glib developers would accept optional libapparmor support
patch.
I apologize to OP Ben for the noise while going a little off-topic.
[0]
https://github.com/GNOME/glib/blob/3bf4a720c315b5015c8d51edf0b458348f796674/gio/glocalfileenumerator.c#L365
[1]
https://github.com/GNOME/glib/blob/9ab0073321c3feaf2584e41701092117a6fb9a1c/gio/glocalfileinfo.c#L1250
[2]
https://github.com/GNOME/glib/blob/cc8b3d6ee203c58a6465c464d71838dd587241eb/gio/gcontenttype.c#L632
