Opened 5 years ago

Closed 5 years ago

#12043 closed defect (fixed)

Stack Trace at SIGTERM when using Sandbox and obfsproxy

Reported by: alphawolf Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version: Tor: 0.2.5.4-alpha
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor built from git (git-767b18ea8eebc2c0), with configure options to mimic Debian packaging. When running as a bridge with obfsproxy and sandbox enabled, SIGTERM causes a stack trace. Also, obfsproxy does not exit and must be killed manually. Without sandbox, obfsproxy closes with tor.

May 19 01:48:11.000 [notice] Catching signal TERM, exiting cleanly.

============================================================ T= 1400478491
(Sandbox) Caught a bad syscall attempt (syscall kill)
/usr/bin/tor(+0x1806e1)[0x7f536e77c6e1]
/lib/x86_64-linux-gnu/libc.so.6(kill+0x7)[0x7f536cc7a697]
/lib/x86_64-linux-gnu/libc.so.6(kill+0x7)[0x7f536cc7a697]
/usr/bin/tor(tor_terminate_process+0x2e)[0x7f536e776473]
/usr/bin/tor(tor_process_handle_destroy+0x40)[0x7f536e776aae]
/usr/bin/tor(+0x4bc56)[0x7f536e647c56]
/usr/bin/tor(pt_free_all+0xb3)[0x7f536e64a437]
/usr/bin/tor(tor_free_all+0x75)[0x7f536e632fa3]
/usr/bin/tor(tor_cleanup+0x174)[0x7f536e633208]
/usr/bin/tor(process_signal+0xc6)[0x7f536e631c43]
/usr/bin/tor(+0x35b67)[0x7f536e631b67]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x9a5)[0x7f536dc88715]
/usr/bin/tor(do_main_loop+0x36f)[0x7f536e631a06]
/usr/bin/tor(tor_main+0x103)[0x7f536e634b11]
/usr/bin/tor(main+0x2f)[0x7f536e62d664]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f536cc66b45]
/usr/bin/tor(+0x31549)[0x7f536e62d549]

/usr/share/tor/tor-service-defaults-torrc:

DataDirectory /var/lib/tor
PidFile /var/run/tor/tor.pid
RunAsDaemon 1
User debian-tor

ControlSocket /var/run/tor/control
ControlSocketsGroupWritable 1

CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /var/run/tor/control.authcookie

Log notice file /var/log/tor/log

torrc:

ORPort 9001
#Nickname Test
#DirPort 9030

ExitPolicy reject *:* # no exits allowed

BridgeRelay 1
ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed
ExtORPort auto

PublishServerDescriptor 0

Sandbox 1

OS: Debian Jessie
kernel: 3.13-1-amd64
libseccomp-dev: 2.1.1-1
obfsproxy: 0.2.8-1

Child Tickets

Change History (3)

comment:1 Changed 5 years ago by alphawolf

Summary: Stack Trace at SIGTERM when using Sanbox and obfsproxyStack Trace at SIGTERM when using Sandbox and obfsproxy

s/Sanbox/Sandbox/ in title...

comment:2 Changed 5 years ago by nickm

I think that the right solution for 0.2.5 is to say that managed proxies aren't supported with sandboxing; we can't expect them to work at all, since even if we do successfully launch them, the sandbox will keep them from calling most of the functions they might want to call.

comment:3 Changed 5 years ago by nickm

Resolution: fixed
Status: newclosed

Should be fixed in 465982012c69e78986d421604d27afd6ecbe70f6 , by refusing to try to use managed proxies or port-forwarding plugins when the sandbox is enabled. Please reopen if it doesn't work. :)

Note: See TracTickets for help on using tickets.