From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lennart Vogelsang via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#63590: 29.0.90; can't load sqlite extension Date: Sat, 20 May 2023 12:39:37 +0200 Message-ID: <99178a26-7148-f4e0-76de-bf2e3bec98af@vogelsang.berlin> References: <2a8d4ca6-1fdf-98c7-6d4b-01f9cca30e8b@vogelsang.berlin> <83mt1zs4qz.fsf@gnu.org> Reply-To: Lennart Vogelsang Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3259"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cc: 63590@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 20 12:40:26 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q0K0f-0000fe-Q4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 20 May 2023 12:40:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q0K0L-00006v-9V; Sat, 20 May 2023 06:40:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q0K0J-00006M-Cl for bug-gnu-emacs@gnu.org; Sat, 20 May 2023 06:40:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q0K0I-00066A-41 for bug-gnu-emacs@gnu.org; Sat, 20 May 2023 06:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q0K0H-0008DD-TB for bug-gnu-emacs@gnu.org; Sat, 20 May 2023 06:40:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lennart Vogelsang Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 May 2023 10:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63590 X-GNU-PR-Package: emacs Original-Received: via spool by 63590-submit@debbugs.gnu.org id=B63590.168457919131545 (code B ref 63590); Sat, 20 May 2023 10:40:01 +0000 Original-Received: (at 63590) by debbugs.gnu.org; 20 May 2023 10:39:51 +0000 Original-Received: from localhost ([127.0.0.1]:57937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q0K06-0008Ci-FN for submit@debbugs.gnu.org; Sat, 20 May 2023 06:39:50 -0400 Original-Received: from mx1.vogelsang.berlin ([195.201.7.160]:11447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q0K04-0008CZ-Ki for 63590@debbugs.gnu.org; Sat, 20 May 2023 06:39:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vogelsang.berlin; s=mx1; t=1684579184; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LuLlA6PcfAwZ3/ewaZy8o0WAFVl/egimkuDptde6qew=; b=MxrGOXWLwewxnff6ikLaXXMXt1GkHY5dzfFpNH1/pfRw7lMCnESqbhmMqb6m+liCjmDJ/0 VvkGdUvWI+49mvRxWkvkz6P0TZYOomNuSRit+mdHStxxLrj4+LJig3BfmXg2WRpGxDLR0o M0KqJcpgoFIBJMqvj0GlgWCYWTRVM0A= Original-Received: from [IPV6:2a02:8109:9d40:1240::9c0c] ( [2a02:8109:9d40:1240::9c0c]) by mx1.vogelsang.berlin (OpenSMTPD) with ESMTPSA id fbeff0e9 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Sat, 20 May 2023 12:39:44 +0200 (CEST) Content-Language: en-US In-Reply-To: <83mt1zs4qz.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:262048 Archived-At: Ahh, I just wanted to answer you, I just noticed that about the tests too. Thank you! Your patch works for me, just one small thing: sqlite extension loading can also fail because of other reasons (e.g. if the shared library does not exist). Currently your patch would leave sqlite extension loading enabled in that case, I think? I would also argue that it would make sense to actually report the error of the extension loading (when  the dynamic library file does not exist, or the extension is invalid). Maybe something like this: diff --git a/src/sqlite.c b/src/sqlite.c index 0361514766a..4be8acc9a94 100644 --- a/src/sqlite.c +++ b/src/sqlite.c @@ -23,6 +23,8 @@ Copyright (C) 2021-2023 Free Software Foundation, Inc.     https://github.com/syohex/emacs-sqlite3  */  #include + +#include  #include "lisp.h"  #include "coding.h" @@ -686,7 +688,8 @@ DEFUN ("sqlite-load-extension", Fsqlite_load_extension,    /* Add names of useful and free modules here.  */    const char *allowlist[3] = { "pcre", "csvtable", NULL };    char *name = SSDATA (Ffile_name_nondirectory (module)); -  /* Possibly skip past a common prefix.  */ +  /* Possibly skip past a common prefix (libsqlite3_mod_ is used by +     Debian, see https://packages.debian.org/source/sid/sqliteodbc).  */    const char *prefix = "libsqlite3_mod_";    if (!strncmp (name, prefix, strlen (prefix)))      name += strlen (prefix); @@ -697,7 +700,7 @@ DEFUN ("sqlite-load-extension", Fsqlite_load_extension,        if (strlen (*allow) < strlen (name)        && !strncmp (*allow, name, strlen (*allow))        && (!strcmp (name + strlen (*allow), ".so") -          || !strcmp (name + strlen (*allow), ".DLL"))) +          || !strcasecmp (name + strlen (*allow), ".dll")))      {        do_allow = true;        break; @@ -707,12 +710,32 @@ DEFUN ("sqlite-load-extension", Fsqlite_load_extension,    if (!do_allow)      xsignal1 (Qsqlite_error, build_string ("Module name not on allowlist")); -  int result = sqlite3_load_extension -               (XSQLITE (db)->db, -            SSDATA (ENCODE_FILE (Fexpand_file_name (module, Qnil))), -            NULL, NULL); -  if (result ==  SQLITE_OK) -    return Qt; +  /* Expand all Lisp data explicitly, so as to avoid signaling an +     error while extension loading is enabled -- we don't want to +     "leak" this outside this function.  */ +  sqlite3 *sdb = XSQLITE (db)->db; +  char *ext_fn = SSDATA (ENCODE_FILE (Fexpand_file_name (module, Qnil))); +  /* Temporarily enable loading extensions via the C API.  */ +  int result = sqlite3_db_config (sdb, SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION, 1, +                  NULL); +  if (result == SQLITE_OK) +    { +      /* save error from sqlite */ +      char *errmsg; +      result = sqlite3_load_extension (sdb, ext_fn, NULL, &errmsg); +      /* Disable loading extensions via C API.  */ +      sqlite3_db_config (sdb, SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION, +             0, NULL); +      if (result == SQLITE_OK) +    { +      return Qt; +    } +      else +    { +      xsignal1 (Qsqlite_error, build_string (errmsg)); +      sqlite_free (errmsg); +    } +    }    return Qnil;  }  #endif /* HAVE_SQLITE3_LOAD_EXTENSION */ That way, the test also correctly fails as we signal the error from the extension loading. Regarding csv.c, yes I forgot to mention that. I admit for testing purposes I changed the name there (to sqlite3_extension_init, which sqlite also always accepts). Thank you for pointing me to the real extension. Just out of curiosity, as there are a handful of useful sqlite extensions out there, could there be a way to make the allow list a bit more lenient? Maybe as a build configure feature allowing us to specify other extensions that are allowed to be loaded. On 5/20/23 11:59 AM, Eli Zaretskii wrote: >> Date: Fri, 19 May 2023 15:25:21 +0200 >> From: Lennart Vogelsang via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> To reproduce, I've created an empty folder, cd'ed into it, started >> emacs -Q, copied the sqlite's csv extension source code [0] into >> csvtable.c, >> compiled it with >> >>      gcc -O3 -Wall -Wno-unknown-pragmas -fPIC -shared -lm -o >> csvtable.so csvtable.c >> >> and executed the following elisp forms in the scratch buffer: >> >>      (setq-local mydb (sqlite-open)) >>      (sqlite-load-extension mydb "./csvtable.so") >> >> I get a nil return value from the second expression, indicating >> that it did not load the extension (verified by using the `csv` module >> in a `sqlite-execute` call). If I try the same from the `sqlite3` cli >> interface, it works: >> >>      .load ./csvtable.so > I think you made one more change to csv.c: you renamed the function > sqlite3_csv_init to the name sqlite3_csvtable_init. Otherwise, the > loading would fail, because sqlite3's cli will not find the entry > function it expects. > > More importantly: the csv.c source file to which you point, viz.: > > https://www.sqlite.org/src/artifact?ci=trunk&filename=ext/misc/csv.c > > is NOT the source file of the libsqlite3_mod_csvtable.so extension > distributed by Debian, which we currently have on the "allow list", it > is a different extension. The source of csvtable is here: > > https://packages.debian.org/sid/libsqlite3-mod-csvtable