[pkg-apparmor] Bug#882048: Bug#882048: Bug#882048: Re: Bug#882048: apparmor should let thunderbird use signatures from files

Vincas Dargis vindrg at gmail.com
Sun Dec 3 11:59:39 UTC 2017


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, 0x00007f833be2c9d0 in open64 () from /lib/x86_64-linux-gnu/libpthread.so.0
$650 = 0x7f8302a0bb20 "/home/vincas/.vimrc"
#0  0x00007f833be2c9d0 in open64 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f8334d3f526 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=<optimized 
out>, fast=0, flags=<optimized out>,
     symlink_broken=<optimized out>, is_symlink=<optimized out>) at ../../../../gio/glocalfileinfo.c:1284
#3  0x00007f8334d40fe9 in _g_local_file_info_get (basename=basename at entry=0x7f831078f120 ".vimrc", 
path=path at entry=0x7f8302a0bb20 "/home/vincas/.vimrc",
     attribute_matcher=<optimized out>, flags=G_FILE_QUERY_INFO_NONE, parent_info=0x7f82fe2290c8, 
error=error at entry=0x7f8316bfddf0) at ../../../../gio/glocalfileinfo.c:1870
#4  0x00007f8334d3e42b in g_local_file_enumerator_next_file (enumerator=0x7f82fe229080, cancellable=<optimized out>, 
error=0x7f8316bfde50)
     at ../../../../gio/glocalfileenumerator.c:407
#5  0x00007f8334cb0930 in next_files_thread (task=0x7f82fe5b2420, source_object=0x7f82fe229080, task_data=<optimized 
out>, cancellable=0x7f8305a504a0)
     at ../../../../gio/gfileenumerator.c:769
#6  0x00007f8334ce8cf6 in g_task_thread_pool_thread (thread_data=0x7f82fe5b2420, pool_data=<optimized out>) at 
../../../../gio/gtask.c:1328
#7  0x00007f8334768000 in g_thread_pool_thread_proxy (data=<optimized out>) at ../../../../glib/gthreadpool.c:307
#8  0x00007f8334767635 in g_thread_proxy (data=0x7f830608edd0) at ../../../../glib/gthread.c:784
#9  0x00007f833be22519 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#10 0x00007f833b0b7a5f in clone () from /lib/x86_64-linux-gnu/libc.so.6
```

```
Thread 93 "pool" hit Breakpoint 1, 0x00007f833be2c9d0 in open64 () from /lib/x86_64-linux-gnu/libpthread.so.0
$1422 = 0x7f8302a66d20 "/home/vincas/.vimrc"
#0  0x00007f833be2c9d0 in open64 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f8334d3f526 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=<optimized 
out>, fast=0, flags=<optimized out>,
     symlink_broken=<optimized out>, is_symlink=<optimized out>) at ../../../../gio/glocalfileinfo.c:1284
#3  0x00007f8334d40fe9 in _g_local_file_info_get (basename=basename at entry=0x7f8315fab290 ".vimrc", path=0x7f8302a66d20 
"/home/vincas/.vimrc",
     attribute_matcher=attribute_matcher at entry=0x7f8302a78820, flags=flags at entry=G_FILE_QUERY_INFO_NONE, 
parent_info=parent_info at entry=0x7f82ea9c5e10,
     error=error at entry=0x7f82ea9c5e80) at ../../../../gio/glocalfileinfo.c:1870
#4  0x00007f8334d3bab7 in g_local_file_query_info (file=0x7f8302a66cc0, attributes=<optimized out>, 
flags=G_FILE_QUERY_INFO_NONE, cancellable=<optimized out>,
     error=0x7f82ea9c5e80) at ../../../../gio/glocalfile.c:1275
#5  0x00007f8334ca8014 in query_info_async_thread (task=0x7f82fe5b3390, object=<optimized out>, task_data=<optimized 
out>, cancellable=<optimized out>)
     at ../../../../gio/gfile.c:5397
#6  0x00007f8334ce8cf6 in g_task_thread_pool_thread (thread_data=0x7f82fe5b3390, pool_data=<optimized out>) at 
../../../../gio/gtask.c:1328
#7  0x00007f8334768000 in g_thread_pool_thread_proxy (data=<optimized out>) at ../../../../glib/gthreadpool.c:307
#8  0x00007f8334767635 in g_thread_proxy (data=0x7f8309cc6ce0) at ../../../../glib/gthread.c:784
#9  0x00007f833be22519 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#10 0x00007f833b0b7a5f 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



More information about the pkg-apparmor-team mailing list