https://bugs.kde.org/show_bug.cgi?id=386746
Bug ID: 386746
Summary: Dragonplayer opens video with read-write mode via
libtag
Product: dragonplayer
Version: unspecified
Platform: Debian testing
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: sit...@kde.org
Reporter: vin...@gmail.com
CC: myr...@kde.org
Target Milestone: ---
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?
--
You are receiving this mail because:
You are watching all bug changes.
