-1

Using php8.1-sqlite3 extension the following PHP script I'm running from CLI:

#!/usr/bin/env php
<?php

require_once('lovefunctions.php') ;
$lov->setLogName(LoveFunctions::MONTHLY_LOG_WITH_HEADER) ;

$db = pdoSQLITE('/m/arm.db') ;
$debug = true ;


function pdoSQLITE($dbPath, $flags = 0) {
    if (substr($dbPath, 0, 7) != 'sqlite:')
        $dbPath = sprintf('sqlite:%s/combadd.sqlite', $dbPath) ;
    try {
        $handle = new PDO($dbPath) ;
        return $handle ;
    }
    catch (Exception $e) {
        throw new Exception($e) ;
    }
}

Script is named /usr/local/bin/browse-arm-db and following output is generated:

[29-Jul-2023 19:55:14 America/New_York] PHP Fatal error:  Uncaught Exception:
PDOException: open_basedir prohibits opening /m/arm.db/combadd.sqlite in /usr/local/bin/browse-arm-db:15
Stack trace:
#0 /usr/local/bin/browse-arm-db(15): PDO->__construct()
#1 /usr/local/bin/browse-arm-db(7): pdoSQLITE()
#2 {main} in /usr/local/bin/browse-arm-db:19
Stack trace:
#0 /usr/local/bin/browse-arm-db(7): pdoSQLITE()
#1 {main}
  thrown in /usr/local/bin/browse-arm-db on line 19

According to phpinfo() the open_basedir value is empty:

> echo '<?php phpinfo();'|php|grep 'open_basedir'
open_basedir => no value => no value

This should be what I want. php.ini says:

; open_basedir, if set, limits all file operations to the defined directory
; and below.  This directive makes most sense if used in a per-directory
; or per-virtualhost web server configuration file.
; Note: disables the realpath cache
; http://php.net/open-basedir
open_basedir =

I have no problem accessing files from any directory (including this file) using file() and file_get_contents etc. Just this PDO open is objecting. How do I access this database using PDO SQLite extension?

NOTE This was originally noted as a PHP7.4 problem on Ubuntu 20.04, but recent testing shows the same problem on PHP8.1.

UPDATE I have moved the arm.db file around, and can find no location that's accepted by the sqlite extension.

Dennis
  • 1,071
  • 2
  • 17
  • 38
  • Is your database actually in `/m/arm.db`? Or maybe something like `/usr/local/m/arm.db`? – Greg Schmidt Jul 30 '23 at 01:11
  • Like it's said in the comments section of the other question, php can have multiple php.ini files. in your place I would run php -i | grep basedir – Your Common Sense Jul 30 '23 at 07:29
  • @GregSchmidt it is actually there. Ideally, when this problem is understood, it won't be in that prominent a location. Historically, /m was a physical drive on windows, and it's been migrated to this server, mounted at /m From a Linux commandline, the command ls -l /m/arm.db result is -rw-r--r--+ 1 dennis dennis 36864 Jul 29 19:21 /m/arm.db – Dennis Jul 31 '23 at 02:33
  • @YourCommonSense php -i is the equivalent of phpino() output. But just for fun, I ran it. Result was as shown in the question: "open_basedir => no value => no value" (It could not have been otherwise) – Dennis Jul 31 '23 at 02:48
  • No, php -i is NOT the equivalent of phpino(). For the reason well explained above. And no, you are doing it not for "fun" but to diagnose your problem. – Your Common Sense Jul 31 '23 at 04:02
  • @YourCommonSense au contraire. https://stackoverflow.com/questions/36006945/what-is-the-difference-between-phpinfo-and-php-i#:~:text=phpinfo()%20is%20a%20language,PHP%20from%20the%20command%20line. Anyway, it's a moot point. The value is unset, as reported by both methods – Dennis Jul 31 '23 at 13:06
  • My bad, i didn't notice you are running phpinfo from command line. – Your Common Sense Jul 31 '23 at 13:24

1 Answers1

0

This was an error in the connection description, a result of misreading this answer to another question. The accepted answer there said:

Try to use PDO instead of sqlite_open:
    $dir = 'sqlite:/[YOUR-PATH]/combadd.sqlite';

Rather than properly research, I took this to mean that /combad.sqlite needed to be added to the end of the path for the connection. I simply didn't take the time to read the question that was being answered.

Changing this value to sqlite:/path/to/my/db ... (in this case, /m/arm.db) I was able to open the file just fine.

Bottom line: Fault was a coding error. But also, PDO, in this case, is issuing an incorrect and misleading error message that led me away from the right answer.

Dennis
  • 1,071
  • 2
  • 17
  • 38