Find an issue sqlite cannot open on some release version of Linux
(1.1) By ralphz on 2023-01-10 03:01:48 edited from 1.0 [source]
Hello ,developers on sqlite. I'm Ralph Zhang from Zoom, as an user of your open source porduct. I have found an issue that the newest sqlite cannot open db on one of our HP customized Linux PC. We have testing the sqlite code on this PC and finally found the return error place is the new add static int unixFullPathname() function. the new function is like static int unixFullPathname( sqlite3_vfs *pVfs, /* Pointer to vfs object */ const char *zPath, /* Possibly relative input path */ int nOut, /* Size of output buffer in bytes */ char *zOut /* Output buffer */ ){ DbPath path; UNUSED_PARAMETER(pVfs); path.rc = 0; path.nUsed = 0; path.nSymlink = 0; path.nOut = nOut; path.zOut = zOut; if( zPath[0]!='/' ){ char zPwd[SQLITE_MAX_PATHLEN+2]; if( osGetcwd(zPwd, sizeof(zPwd)-2)==0 ){ return unixLogError(SQLITE_CANTOPEN_BKPT, "getcwd", zPath); } appendAllPathElements(&path, zPwd); } appendAllPathElements(&path, zPath); zOut[path.nUsed] = 0; if( path.rc || path.nUsed<2 ) return SQLITE_CANTOPEN_BKPT; if( path.nSymlink ) return SQLITE_OK_SYMLINK; return SQLITE_OK; } It looks like to expand the full path on unix. In the HP's system, the file path is " /home/user/xxx " ,but the "home" path is linked to "../writalbe/home" actually. So the input path will be expand to "../writalbe/home/user/xxx " by osGetcwd(zPwd, sizeof(zPwd)-2)==0. Then when the function call appendAllPathElements(&path, zPwd); IT will return error at if( nName==1 ) return; if( zName[1]=='.' && nName==2 ){ if( pPath->nUsed<=1 ){ pPath->rc = SQLITE_ERROR; return; } bacause the path now is "../writalbe/home/user/xxx " start with "../" ,It's a relative path. And it works good on old version of sqlite. So does it have some security concerns that make this change? The path might be linked as relative path in some system, I think we can fix the issue in this case by changing the expand and check path order. If you have any updates, please contact me at ralph.zhang@zoom.us. Thanks!
(2) By Donal Fellows (dkfellows) on 2023-01-10 09:46:08 in reply to 1.1 [link] [source]
And it works good on old version of sqlite.
It helps the team if you say which version of the SQLite library you have found it fails with and which one it works with.
(4) By ralphz on 2023-01-10 13:43:41 in reply to 2 [link] [source]
The 3.36.0 is ok. And the 3.39.2 doesn't work well
(3) By Dan Kennedy (dan) on 2023-01-10 11:19:26 in reply to 1.1 [link] [source]
In the HP's system, the file path is " /home/user/xxx " ,but the "home" path is > linked to "../writalbe/home" actually. So the input path will be expand to "../writalbe/home/user/xxx " by osGetcwd(zPwd, sizeof(zPwd)-2)==0.
It's probably just me being slow, but I don't quite follow. How can /home be linked to ../writable/home?
Can you show us the symlink with [ls -l] and then give an example of a database path that fails to open (and the cwd when the failed open is attempted)?
Thanks,
Dan.
(6) By ralphz on 2023-01-10 14:04:38 in reply to 3 [link] [source]
The ls shows total 44 drwxr-xr-x 1 root root 206 Jan 13 2021 . Irwxrwxrwx 1 root root 14 Jan 13 2021 etc -> ./writable/etc. lruxrwxrwx 1 root root 16 Jan 13 2021 home -> ../writable/home ... ... drwxr-xr-x 1 root root 56 Jan 13 2021 usr drwxr-xr-x 1 root root 96 Dec 1 14:34 writable The file path failed to open is " /home/user/app/.data/xxxx.db " It's working on the ".data/" directory Thanks for your help Ralph
(7) By TripeHound on 2023-01-10 14:28:05 in reply to 6 [link] [source]
You might think me nit-picky, but sometimes when debugging, the devil is in the details...
Does
etc
really point to awriteable
in the same directory, whereashome
points to one in the parent directory?Does the pointed-to
etc
really end with a fullstop?Does the path that fails to open really begin and end with a space?
(11) By anonymous on 2023-01-10 20:24:20 in reply to 7 [link] [source]
I have a Linux Ubuntu machine. Directory and File names honour the original Unix naming convention. The names are Unix strings. Unix strings end with a null value. The ls command use a single quote to help readability. So, in my home directory I have: kevin@linux:~$ touch harry kevin@linux:~$ touch harry. kevin@linux:~$ mkdir 'harry_with_space ' kevin@linux:~$ ls -lai harry* 2095118 -rw-rw-r-- 1 kevin kevin 0 Jan 11 07:08 harry harry.: total 8 2095105 drwxrwxr-x 2 kevin kevin 4096 Jan 11 07:08 . 2093058 drwxr-xr-x 21 kevin kevin 4096 Jan 11 07:09 .. 'harry_with_space ': total 8 2095122 drwxrwxr-x 2 kevin kevin 4096 Jan 11 07:09 . 2093058 drwxr-xr-x 21 kevin kevin 4096 Jan 11 07:09 .. However, try to enter a ' and you get stuck.
(5) By Richard Hipp (drh) on 2023-01-10 13:58:47 in reply to 1.1 [link] [source]
I tried to reply to this yesterday, but apparently I forgot to press "Submit"...
I spent some time trying to recreate the problem and have so far been unsuccessful. The OP needs to give is more detail and/or a better description of what he is doing or what is the perceived malfunction.
(8) By Richard Hipp (drh) on 2023-01-10 15:11:13 in reply to 1.1 [link] [source]
It turns out that on unix, the "/" directory is considered to be its own parent directory. So "/../" is the same as "/". I didn't know that and so that corner case was not accounted for in the SQLite code.
Dan checked in a fix a few minutes ago.
(9.1) By jose isaias cabrera (jicman) on 2023-01-10 17:22:50 edited from 9.0 in reply to 8 [link] [source]
... So "/../" is the same as "/".
Interestingly enough, \..\, in Windows is the the same as C:\ also. Did not know that either.
(10) By Keith Medcalf (kmedcalf) on 2023-01-10 17:43:33 in reply to 9.1 [link] [source]
That is only if the current directory is on the C: drive. If the current directory is on the Q: drive, then \..\ is the same as Q:\
That is x:\..\ is the same as x:\