Bug 386746

While developing usr.bin.dragon AppArmor profile on Debian Testing I have discovered that Dragonplayer 16.08.3-1 tries to open video file in question with O_RDWR flags, which is unexpected behavior for *viewing* a video file.

Idea of AppArmor profile is to limit what application can do, and I would not like to allow it to write arbitrary files, obviously. I do allow reading in $HOME/not-dot-file-or-dir*  so that user could open whenever video file it wants, but if Dragonplayer tries to "write" a video file (simply open with write flags on, that is), AppArmor produces DENIED message like this, which is noisy:

type=AVC msg=audit(1510258054.061:807): apparmor="DENIED" operation="open" profile="/usr/bin/dragon" name=2F686F6D652F76696E6361732F5061727369756E74696D61692F4167656E7420333237204F7065726174696F6E2042617262657273686F702E6D7034 pid=14004 comm="dragon" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
type=SYSCALL msg=audit(1510258054.061:807): arch=c000003e syscall=2 success=no exit=-13 a0=7fc5d41024b0 a1=2 a2=1b6 a3=0 items=0 ppid=13996 pid=14004 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts3 ses=16 comm="dragon" exe="/usr/bin/dragon" key=(null)
type=PROCTITLE msg=audit(1510258054.061:807): proctitle=2F7573722F62696E2F647261676F6E002F686F6D652F76696E6361732F5061727369756E74696D61692F4167656E7420333237204F7065726174696F6E2042617262657273686F702E6D7034

Using sysdig, we can see open() syscalls, of which one of them got EACCESS due to O_RDWR, produced by AppArmor file access mediation:

sudo sysdig "proc.name=dragon and evt.type=open and fd.name contains Agent "
203488 14:21:07.817722738 1 dragon (19516) < open fd=25(<f>/home/vincas/Parsiuntimai/Agent 327 Operation Barbershop.mp4) name=/home/vincas/Parsiuntimai/Agent 327 Operation Barbershop.mp4 flags=4097(O_RDONLY|O_CLOEXEC) mode=0 
230268 14:21:07.831692519 7 dragon (19524) < open fd=25(<f>/home/vincas/Parsiuntimai/Agent 327 Operation Barbershop.mp4) name=/home/vincas/Parsiuntimai/Agent 327 Operation Barbershop.mp4 flags=4161(O_NONBLOCK|O_RDONLY|O_CLOEXEC) mode=0 
231644 14:21:07.832439252 7 dragon (19524) < open fd=25(<f>/home/vincas/Parsiuntimai/Agent 327 Operation Barbershop.mp4) name=/home/vincas/Parsiuntimai/Agent 327 Operation Barbershop.mp4 flags=4161(O_NONBLOCK|O_RDONLY|O_CLOEXEC) mode=0 
258229 14:21:07.900294935 7 dragon (19524) < open fd=-13(EACCES) name=/home/vincas/Parsiuntimai/Agent 327 Operation Barbershop.mp4 flags=3(O_RDWR) mode=0 
258232 14:21:07.900298706 7 dragon (19524) < open fd=26(<f>/home/vincas/Parsiuntimai/Agent 327 Operation Barbershop.mp4) name=/home/vincas/Parsiuntimai/Agent 327 Operation Barbershop.mp4 flags=1(O_RDONLY) mode=0


Looking at the audit log, we can see troubled open() syscall arguments: 

a0=7fc5d41024b0 a1=2 a2=1b6

So I've tried to breakpoints on open() with arguments mentioned like this using GDB:

break open if ($rsi == 2) && ($rdx == 0x1b6)

Breakpoint has triggered with backtrace like this:

#0  0x00007fc61316c490 in open64 () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fc613104293 in _IO_file_open () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007fc613104433 in _IO_file_fopen () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007fc6130f85b4 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007fc5b6506147 in TagLib::FileStream::FileStream(char const*, bool) () from /lib/x86_64-linux-gnu/libtag.so.1
#5  0x00007fc5b6504e02 in TagLib::File::File(char const*) () from /lib/x86_64-linux-gnu/libtag.so.1
#6  0x00007fc5b651b440 in TagLib::MP4::File::File(char const*, bool, TagLib::AudioProperties::ReadStyle) () from /lib/x86_64-linux-gnu/libtag.so.1
#7  0x00007fc5b652f6e3 in ?? () from /lib/x86_64-linux-gnu/libtag.so.1
#8  0x00007fc5b652fa46 in TagLib::FileRef::FileRef(char const*, bool, TagLib::AudioProperties::ReadStyle) () from /lib/x86_64-linux-gnu/libtag.so.1
#9  0x00007fc5b67a686d in ?? () from /usr/lib/x86_64-linux-gnu/vlc/plugins/meta_engine/libtaglib_plugin.so
#10 0x00007fc5f737cb3d in ?? () from /lib/x86_64-linux-gnu/libvlccore.so.8
#11 0x00007fc5f737d076 in vlc_module_load () from /lib/x86_64-linux-gnu/libvlccore.so.8
#12 0x00007fc5f7340c5f in ?? () from /lib/x86_64-linux-gnu/libvlccore.so.8
#13 0x00007fc5f7342e72 in ?? () from /lib/x86_64-linux-gnu/libvlccore.so.8
#14 0x00007fc5f7346d16 in ?? () from /lib/x86_64-linux-gnu/libvlccore.so.8
#15 0x00007fc610066494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#16 0x00007fc613179abf in clone () from /lib/x86_64-linux-gnu/libc.so.6

To check if it's actually the case:

gdb) print (char*)$rdi
$1 = 0x7f54ac0c52b0 "/home/vincas/Parsiuntimai/Agent 327 Operation Barbershop.mp4"

And after stepping in GDB, I got audit log message about AppArmor's deny, so I am pretty sure it's opened within `TagLib::FileStream::FileStream(char const*, bool)` in libtag.so, via libvlccore.so.

Question is, could this be Dragonplayer bug in the sense that some incorrect flags are passed (I assume that writing is not intentional) to the VLC backend, or it's libvlccore that "decided" to instruct libtag to open for writing?

Or writing is actually by design?