Way back on 2015-04-10 I started the following thread about what may or may not have been a related symlink bug to the one I intend to describe here today:
http://forum.kodi.tv/showthread.php?tid=223971
I provide the above link for the sake of completness. I don’t know if that (NFS/symlinks) bug from 2015 is directly related to the one I wish to describe here today or not, but it seems possible, if not to say likely.
I am informally reporting the following bug here today just to ask if others can reproduce it. If so, I will file a formal bug report for it.
Bug Description:
If, on some NFS exported volume residing on some NFS server, a relative symlink (RS0) is created which (a) points to a directory and which also (b) itself begins with a leading “..” (dot-dot) pathname component, and if the target directory of the symlink (and/or some subdirectory/subdirectories thereof) itself/themselves also contain(s) one or more (secondary) relative symlinks (RSn) which themselves begin with leading “..” (dot-dot) pathname components, then if the NFS volume in question is browsed using Kodi, and if the original symlink (RS0) is traversed during this browsing, then any and all of the secondary relative symlinks will fail to even appear in Kodi directory listings during such browsing.
Important: Note that the secondary symlinks in such scenarios will appear in the Kodi directory listings, even when the original symlink (RS0) is followed, if and only if the target directory of the original symlink (RS0) has already been visited (during Kodi file/directory browsing) directly, i.e. without traversing the original symlink (RS0). In other words, there seems to be some sort of caching effect involved here. If you visit the target directory directly, without going through the (relative dot-dot) symlink, then you will see all of its contents properly, including any relative dot-dot symlinks contained therein. After you have done that once, then you can also browse back to that same directory via the symlink and now everything that should appear in that directory will appear in that directory, at least until you stop and restart Kodi, and then try browsing back to that same directory via the relative dot-dot symlink again. If you do that again, just after restarting Kodi, then again, the contents of the target directory will fail to show any other relative dot-dot symlinks that are present in there (but other things that are present in that directory, e.g. plain files, directories, and even non-relative or non-dot-dot symlinks will also show up properly there).
Important: This bug(s) require a variety of obscure factors to all be in perfect alignment in order to reproduce the bug(s). In particular, in the description of how to reproduce the bug(s), as given below, if any change is made, either to the specific filenames used, or to the ordering in which the steps are carried out, then the bug(s) may no longer present themselves. In my opinion, this is most likely indicative of the presence of multiple design errors, either in Kodi proper and/or in the NFS client library it is built with.
Affected:
Kodi on Android – Affected (16.1 Git:2016-04-24-f6ceced / Android 5.1.1)
SMPC on Android – Affected (SPMC 16.4-2 git:2016-08-15-46f733d-dirty / Android 5.1.1)
LibreELEC(arm) – Affected (Kodi 16.1 Git:c327c53 / LibreELEC 7.0.2.008)
Kodi on Ubuntu – affected (15.2 Git:(unknown)) (Compiled: 15.2+dfsg1+3ubuntu1 / Ubuntu 16.04 LTS)
Unaffected:
Kodi on Windows 7 (16.1)
How to Reproduce:
On the NFS server:
Login
cd to some convenient directory on some NSF exported filesystem
mkdir test
cd test
mkdir dir1
mkdir dir2
cd dir1
ln -s ../afile.jpg symlink-a.jpg
cd ../dir2
ln -s ../dir1 symlink-b
cd ..
cp <<someimagefile>>.jpg ./afile.jpg
On the NFS client (i.e. something running Kodi):
Shutdown Kodi/LibreELEC/SPMC — power off if necessary
Re-start Kodi/LibreELEC/SPMC
If you have not already done so, go to Pictures->Files->Add Pictures… and add a source of the form:
nfs://<<IPv4 addr>>/path
where the URL designates the NFS volume within which you created the test directory in the steps above.
When done, go back to Pictures->Files and select this same NFS source
Browse to the test directory you created on the NFS server
While in that “test” directory do not browse into dir1.
Browse into dir2
While you are within dir2, click on symlink-b
Note that after you do so, the directory listing will be empty except for the dot-dot — this is the bug
Click on the dot-dot to return to the directory you came from (dir2)
Click on the dot-dot to return to the test directory
Browse into the dir1 directory and note the correct presence of the symlink-a.jpg file/symlink
Click on the dot-dot to return to the test directory
Browse into dir2 (again)
While you are within dir2, click on symlink-b (again)
Note that now you will see the directory entry for symlink-a.jpg there. (This proves that the bug can be, and perhaps often will be hidden by caching effects.)
I would appreciate it if others would try to reproduce this bug/bugs using exactly the above steps and let me know if you can. Remember, if you change the order of the steps, or even just the filenames or directory names used, you may not see the bug(s). I tried using different filenames/directory names and/or a different ordering of the steps and in all those cases I was not able to reproduce the bug(s).
P.S. Just because all of the planets have to be in perfect alignment before one can reliably and repeatedly reproduce this bug/bugs, that does not mean it isn’t potentially serious. Indeed, innumerable serious security bugs have been documented, over time, which relate to the explotation of directory traversal hacks involving “../”.