Solved CFileUtils::CheckFileAccessAllowed web interface issues with how NixOS uses symlinks
#1
I recently dug into this NixOS issue where the Kodi web interface was returning a "File not found" message rather than the chorus2 interface: https://github.com/NixOS/nixpkgs/issues/145116.

The problem ended up being related to how NixOS installs kodi addons: it create a "wrapper" for kodi that sets up a `KODI_HOME`. I'm happy to explain all the details if necessary, but the short version of the story is that on my machine, kodi ends up running with a KODI_HOME that looks like this:

bash:

$ eval $(cat /proc/$(pgrep kodi | head -1)/environ | grep -Pao 'KODI_HOME[^\x00]*')  # clever trick to load the KODI_HOME environment variable from a running kodi process
$ echo $KODI_HOME
/nix/store/2rvg4dws7dkgjvnvaqnc71lc59xfh40k-kodi-19.3-env/share/kodi
$ ls -alh $KODI_HOME/addons/
dr-xr-xr-x 3 root root 4.0K Dec 31  1969 .
dr-xr-xr-x 4 root root 4.0K Dec 31  1969 ..
...
lrwxrwxrwx 1 root root  114 Dec 31  1969 script.module.requests -> /nix/store/62zc1i8ranzad3s184fvzng8bflq5gh9-kodi-requests-2.25.1+matrix.1/share/kodi/addons/script.module.requests
lrwxrwxrwx 1 root root  104 Dec 31  1969 script.module.six -> /nix/store/2vfpwh5ppw21vg1b9dr4j96klg463v5v-kodi-six-1.15.0+matrix.1/share/kodi/addons/script.module.six
lrwxrwxrwx 1 root root  112 Dec 31  1969 script.module.urllib3 -> /nix/store/5pgnlh037y212p0mnnqbb2r0pfsfijss-kodi-urllib3-1.26.4+matrix.1/share/kodi/addons/script.module.urllib3
lrwxrwxrwx 1 root root   87 Dec 31  1969 script.parsec -> /nix/store/wgpjc5hxi20xyjn75qapzb22dlgp159n-kodi-parsec/share/kodi/addons/script.parsec
lrwxrwxrwx 1 root root  106 Dec 31  1969 script.tubecast -> /nix/store/kav53h66gp6l92p3zw2wlpjx4skx272j-kodi-tubecast-1.4.8+matrix.1/share/kodi/addons/script.tubecast
lrwxrwxrwx 1 root root  116 Dec 31  1969 service.subtitles.a4ksubtitles -> /nix/store/p3ayh07z4vjqa677b6fz5h41h3w9czsd-kodi-a4ksubtitles-2.8.0/share/kodi/addons/service.subtitles.a4ksubtitles
lrwxrwxrwx 1 root root   97 Dec 31  1969 service.xbmc.versioncheck -> /nix/store/kghmcd45b2qij9a6adyvzdvfdk7ziiv9-kodi-19.3/share/kodi/addons/service.xbmc.versioncheck
lrwxrwxrwx 1 root root   85 Dec 31  1969 skin.estouchy -> /nix/store/kghmcd45b2qij9a6adyvzdvfdk7ziiv9-kodi-19.3/share/kodi/addons/skin.estouchy
lrwxrwxrwx 1 root root   84 Dec 31  1969 skin.estuary -> /nix/store/kghmcd45b2qij9a6adyvzdvfdk7ziiv9-kodi-19.3/share/kodi/addons/skin.estuary
lrwxrwxrwx 1 root root  102 Dec 31  1969 vfs.libarchive -> /nix/store/8wsbsx9y4s50y6d61lwyl9bvq2p841jk-kodi-vfs.libarchive-2.0.0/share/kodi/addons/vfs.libarchive
dr-xr-xr-x 8 root root 4.0K Dec 31  1969 webinterface.default
lrwxrwxrwx 1 root root   82 Dec 31  1969 xbmc.addon -> /nix/store/kghmcd45b2qij9a6adyvzdvfdk7ziiv9-kodi-19.3/share/kodi/addons/xbmc.addon
lrwxrwxrwx 1 root root   81 Dec 31  1969 xbmc.core -> /nix/store/kghmcd45b2qij9a6adyvzdvfdk7ziiv9-kodi-19.3/share/kodi/addons/xbmc.core
lrwxrwxrwx 1 root root   80 Dec 31  1969 xbmc.gui -> /nix/store/kghmcd45b2qij9a6adyvzdvfdk7ziiv9-kodi-19.3/share/kodi/addons/xbmc.gui
lrwxrwxrwx 1 root root   81 Dec 31  1969 xbmc.json -> /nix/store/kghmcd45b2qij9a6adyvzdvfdk7ziiv9-kodi-19.3/share/kodi/addons/xbmc.json
...

I've truncated the output, but hopefully it's obvious how everything here is a symlink, except for `webinterface.default`, which is a regular folder because of this "hack" I just got merged up to NixOS. (This doesn't feel like the right long term solution because it special cases webinterface.default, and therefore is not going to handle other addons.)

If the webinterface.default ends up being a symlink, then CFileUtils::CheckFileAccessAllowed ends up denying access because the realpath of files inside that folder are *not* underneath any of the whitelist paths (specifically, "special://xbmc" in this case).

Would y'all be open to some sort of change to kodi to let this work on NixOS? Some ideas:

1. Kodi could expose some hook to add entries into this whitelist.
2. Kodi could expose some option to "dangerously" turn off this call to realpath. This might be analogous to apache's FollowSymLinks option, although I'm not fully grok-ing the docs on it. It is interesting to note that maybe the call to realpath isn't actually protecting us from much. From the apache docs:
Quote:Omitting this option should not be considered a security restriction, since symlink testing is subject to race conditions that make it circumventable.

Thanks in advance! Kodi is a wonderful piece of software.
Reply
#2
I'm not familiar with how nixOS packaging works, but it certainly seems particular. I suggest but simply add a patch to your packaging, adding the path to the whitelist.
Reply
#3
Thanks for the feedback @wsnipex. Is there any chance Team Kodi would accept a patch to allow adding paths to the whitelist, even if at build time? Always a bonus if NixOS doesn't have to maintain separate patches against upstream.
Reply
#4
I would be ok with adding a build time cmake option
Reply
#5
Great! Thank you very much @wsnipex! We'll take this back, work something out, and then ping you in a PR. Much appreciated.
Reply
#6
I found some time today to put together a RFC: https://github.com/xbmc/xbmc/pull/21113. Hopefully the idea makes sense!
Reply
#7
fix merged, so marking this as solved
Reply
#8
Thanks, wsnipex!
Reply

Logout Mark Read Team Forum Stats Members Help
CFileUtils::CheckFileAccessAllowed web interface issues with how NixOS uses symlinks0