Permission failures when creating the database causes a segfault

[ollien]

Summary

When putting together a project of mine, I was getting an unexplainable segfault for quite some time. After some digging, I noticed that it went away when my application was run as root in my Docker container, which hinted it might be permission related. Some googling later, I found this post on the Elixir Forum, which suggested the same; I eventually discovered that this was due to the fact that I was attempting to create a database in a directory where I did not have permission to do so.

Reproduction

1. Configure Ecto to use a database in a directory where it does not have permission to write to; this database should not exist.
2. Either run the application, or run mix ecto.create (both produce this segfault)

I have assembled a repo which contains a minimal project that can reproduce this issue. Note that I have pointed the repo to /etc, which on my system (and in most distros), is not writable by non-root users; you may need to change this to another location in order to perform the reproduction.

I have successfully reproduced this both on my Fedora 36 system and a Debian 11 docker image.

Stacktrace

           PID: 1722769 (beam.smp)
           UID: 1000 (nick)
           GID: 1000 (nick)
        Signal: 11 (SEGV)
     Timestamp: Sun 2023-02-26 17:49:43 EST (2min 36s ago)
  Command Line: /usr/lib64/erlang/erts-12.3.2.8/bin/beam.smp -- -root /usr/lib64/erlang -progname erl -- -home /home/nick -- -pa /usr/share/elixir/1.14.3/bin/../lib/eex/ebin /usr/share/elixir/1.14.3/bin/../lib/elixir/ebin /usr/share/elixir/1.14.3/bin/../lib/ex_unit/ebin /usr/share/elixir/1.14.3/bin/../lib/iex/ebin /usr/share/elixir/1.14.3/bin/../lib/logger/ebin /usr/share/elixir/1.14.3/bin/../lib/mix/ebin -elixir ansi_enabled true -noshell -s elixir start_cli -extra /usr/bin/mix ecto.create
    Executable: /usr/lib64/erlang/erts-12.3.2.8/bin/beam.smp
 Control Group: /user.slice/user-1000.slice/session-2.scope
          Unit: session-2.scope
         Slice: user-1000.slice
       Session: 2
     Owner UID: 1000 (nick)
       Boot ID: f9cb22e8440c4bd4b1139db62b385a66
    Machine ID: c38e5ea9b4f440e4a0d236752b998731
      Hostname: cubert
       Storage: /var/lib/systemd/coredump/core.beam\x2esmp.1000.f9cb22e8440c4bd4b1139db62b385a66.1722769.1677451783000000.zst (present)
     Disk Size: 13.6M
       Package: erlang/24.3.4.8-1.fc36
      build-id: 40c2cd1d35bd2044cec23d59e0846fdb3ccd59d9
       Message: Process 1722769 (beam.smp) of user 1000 dumped core.
                
                Module /home/nick/Documents/code/ecto_sqlite_segfault_repro/_build/dev/lib/exqlite/priv/sqlite3_nif.so with build-id 5409869dd1671fbb433444416143db7c815811ce
                Metadata for module /home/nick/Documents/code/ecto_sqlite_segfault_repro/_build/dev/lib/exqlite/priv/sqlite3_nif.so owned by FDO found: {
                	"type" : "rpm",
                	"name" : "erlang",
                	"version" : "24.3.4.8-1.fc36",
                	"architecture" : "x86_64",
                	"osCpe" : "cpe:/o:fedoraproject:fedora:36"
                }
                
                Module linux-vdso.so.1 with build-id f9108be66fa57e741e149d8b7563f11b937149b6
                Module libsctp.so.1 with build-id 4e91c8e74cc6c0f89ed4cdff3669662d5b94a66b
                Metadata for module libsctp.so.1 owned by FDO found: {
                	"type" : "rpm",
                	"name" : "lksctp-tools",
                	"version" : "1.0.18-12.fc36",
                	"architecture" : "x86_64",
                	"osCpe" : "cpe:/o:fedoraproject:fedora:36"
                }
                
                Module ld-linux-x86-64.so.2 with build-id 321b87738a8ee7220b3c045c0d4d93150be54470
                Module libc.so.6 with build-id 8257ee907646e9b057197533d1e4ac8ede7a9c5c
                Module libgcc_s.so.1 with build-id cbcf5689acb247f987a22375c392c19a530a85c0
                Module libm.so.6 with build-id 7c51a65c054f2ddc34c8325d82a1150f580f0d91
                Module libstdc++.so.6 with build-id 6ce2a41dee893f9ede3c63f9aadad3826220476e
                Module libz.so.1 with build-id aec7e77c3a6ce5dd195a8c86a8fb1178715cf45f
                Metadata for module libz.so.1 owned by FDO found: {
                	"type" : "rpm",
                	"name" : "zlib",
                	"version" : "1.2.11-33.fc36",
                	"architecture" : "x86_64",
                	"osCpe" : "cpe:/o:fedoraproject:fedora:36"
                }
                
                Module libtinfo.so.6 with build-id 954d12f7d8216fde821db122a4768ee255382a63
                Metadata for module libtinfo.so.6 owned by FDO found: {
                	"type" : "rpm",
                	"name" : "ncurses",
                	"version" : "6.2-9.20210508.fc36",
                	"architecture" : "x86_64",
                	"osCpe" : "cpe:/o:fedoraproject:fedora:36"
                }
                
                Module beam.smp with build-id 40c2cd1d35bd2044cec23d59e0846fdb3ccd59d9
                Metadata for module beam.smp owned by FDO found: {
                	"type" : "rpm",
                	"name" : "erlang",
                	"version" : "24.3.4.8-1.fc36",
                	"architecture" : "x86_64",
                	"osCpe" : "cpe:/o:fedoraproject:fedora:36"
                }
                
                Stack trace of thread 1722782:
                #0  0x00007fd962e8f755 __pthread_mutex_destroy@GLIBC_2.2.5 (libc.so.6 + 0x8f755)
                #1  0x0000555b12852412 enif_mutex_destroy (beam.smp + 0x294412)
                #2  0x0000555b1285822d run_resource_dtor (beam.smp + 0x29a22d)
                #3  0x0000555b1262e8f6 handle_aux_work.lto_priv.0 (beam.smp + 0x708f6)
                #4  0x0000555b126454da erts_schedule (beam.smp + 0x874da)
                #5  0x00007fd913000230 n/a (n/a + 0x0)
                ELF object binary architecture: AMD x86-64

[warmwaffles]

I'll hop on this as soon as I can. This should be resolvable in the c_src to properly check the error codes.

[warmwaffles]

I haven't forgotten about this. Just a little swamped with work.

[ollien]

No worries, this is an open source project after all. I don't have any expectations for a quick fix but I certainly do appreciate your thoughtfulness!!

[warmwaffles]

I've got a fix for this. Turns out tear down procedure was causing issues. The connection_type_destructor was trying to use an invalid pointer to close with.

[warmwaffles]

@ollien this will be released under v0.13.8

[liamdiprose]

Bet me to it. Thanks for this.

[warmwaffles]

😉 I finally got some free time today 😄