On Sun, May 13, 2018 at 05:00:56PM +0900, Bryan Linton wrote: > On 2018-05-12 20:02:40, Landry Breuil <lan...@openbsd.org> wrote: > > On Sat, May 12, 2018 at 08:07:17PM +0900, Bryan Linton wrote: > > > > > > Adding the "getpw" pledge to "security.sandbox.pledge.content" > > > doesn't fix it. However adding it to "security.sandbox.pledge.main" > > > lets everything run just fine again. > > > > Well, i can't reproduce it here, and i have no issue calling 'save link > > as' or 'save page as' dialogs without getpw pledge on main process. > > Though i havent tried *actually* saving the image/page. > > > > I'll need a bit more context.. can you look at the coredump with egdb > > from ports and try to get the backtrace for the pledge abort, so that we > > figure out if it's within firefox or the glib layers ? > > > > % dmesg | grep GENERIC | tail -2 > OpenBSD 6.3-current (GENERIC.MP) #14: Thu Apr 26 21:03:52 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > % ls -la /etc/malloc.conf > ls: /etc/malloc.conf: No such file or directory > > % firefox -profilemanager > [create new, blank profile with no add-ons or extensions installed] > > [firefox gets killed by pledge() upon "Right-click -> Save link as..."] > firefox[99269]: pledge "getpw", syscall 33 > > Program terminated with signal SIGILL, Illegal instruction. > #0 0x0000000000000000 in ?? () > [Current thread is 1 (process 127256)] > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x00000fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from > /usr/local/lib/firefox/libxul.so.77.0 > #2 <signal handler called> > #3 0x0000000000000000 in ?? () > #4 0x00000fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from > /usr/local/lib/firefox/libxul.so.77.0 > #5 <signal handler called> > #6 0x0000000000000000 in ?? () > #7 0x00000fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from > /usr/local/lib/firefox/libxul.so.77.0 > #8 <signal handler called> > #9 0x0000000000000000 in ?? () > #10 0x00000fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from > /usr/local/lib/firefox/libxul.so.77.0 > > [...many identical lines deleted] > > #2323 0x00000fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from > /usr/local/lib/firefox/libxul.so.77.0 > #2324 <signal handler called> > #2325 0x0000000000000000 in ?? () > #2326 0x00000fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from > /usr/local/lib/firefox/libxul.so.77.0 > #2327 <signal handler called> > #2328 0x00000fea53142659 in > mozilla::ipc::MessageChannel::OnChannelErrorFromLink() () from > /usr/local/lib/firefox/libxul.so.77.0 > #2329 0x00000fea53143c31 in non-virtual thunk to > mozilla::ipc::ProcessLink::OnChannelError() () from > /usr/local/lib/firefox/libxul.so.77.0 > #2330 0x00000fea53127a2e in event_persist_closure () > at > /usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1580 > #2331 event_process_active_single_queue () > at > /usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1639 > #2332 0x00000fea531251fe in event_process_active () > at > /usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1741 > #2333 event_base_loop () at > /usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1961 > #2334 0x00000fea531129c5 in > base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) () from > /usr/local/lib/firefox/libxul.so.77.0 > #2335 0x00000fea53111417 in MessageLoop::Run() () from > /usr/local/lib/firefox/libxul.so.77.0 > #2336 0x00000fea5311bf35 in base::Thread::ThreadMain() () from > /usr/local/lib/firefox/libxul.so.77.0 > #2337 0x00000fea53116f0a in ThreadFunc(void*) () from > /usr/local/lib/firefox/libxul.so.77.0 > #2338 0x00000fea86975e7e in _rthread_start (v=0xfea57f21ed7) at > /usr/src/lib/librthread/rthread.c:96 > #2339 0x00000fea6eb1ed8b in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 > #2340 0x0000000000000000 in ?? ()
Sadly, this trace doesnt really help, since it seems to be a signal handler that catches the SIGABRT, or the signal handler is in the main process and the abort is in the content process, and not the trace of the codepath that triggers this SIGABRT... How about trying it live (if you can) within egdb following all processes, with a breakpoint on signal or SYS_access ? Thanks !
