Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 364877 - sys-apps/sandbox issue with static binaries, pipes and FD_CLOEXEC
Summary: sys-apps/sandbox issue with static binaries, pipes and FD_CLOEXEC
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Sandbox (show other bugs)
Hardware: x86 Linux
: Normal blocker (vote)
Assignee: Sandbox Maintainers
URL: http://bugs.python.org/issue11915
Whiteboard:
Keywords:
: 452796 (view as bug list)
Depends on:
Blocks: 438070 438090 438576 438578 438580 438582
  Show dependency tree
 
Reported: 2011-04-25 23:54 UTC by Victor Stinner
Modified: 2013-12-03 16:41 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Testcase to demonstrate the bug (require static.c) (sandbox_exec_bug.c,1.52 KB, text/plain)
2011-04-25 23:55 UTC, Victor Stinner
Details
Dummy static binary writing 1 MB into stdout (used by sandbox_exec_bug.c) (static.c,206 bytes, text/plain)
2011-04-25 23:56 UTC, Victor Stinner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Stinner 2011-04-25 23:54:08 UTC
Arfrever Frehtes Taifersar Arahesis opened an issue in Python bug tracker:
http://bugs.python.org/issue11915

But the issue comes from sandbox, not from Python (from ctypes.find_util()): subprocess.Popen(['ldconfig', '-p'], stdout=subprocess.PIPE) hangs in sandbox. The parent process hangs on reading a pipe used to transfer an exception from the child process. The child process is supposed to close this pipe at exec().

The child process hangs before calling execve() syscall, or it doesn't close the pipe on execve().

sandbox_exec_bug.c+static.c demonstrates the bug. It's a testcase extracted from the Python source code and rewritten in C. The parent process waits on the error pipe, which is supposed to be closed quickly (on child exec). The parent is supposed to read the output pipe just when the error pipe is closed. The child hangs on writing into the output pipe because it is full.

Reproducible: Always

Steps to Reproduce:
1. gcc sandbox_exec_bug.c -o sandbox_exec_bug
2. gcc -static static.c -o static
3. sandbox ./sandbox_exec_bug
Actual Results:  
It hangs. It doesn't hang if static.c is not compiled as a static binary.

Expected Results:  
Should finish quickly (less than one second).

sandbox traces:

trace_main tracing: ./static
TRACE (pid=10377):trace_main: parent waiting for child (pid=10378) to signal
TRACE (pid=10378):trace_main: child setting up ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGSTOP(19)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGCONT(18)
TRACE (pid=10377):trace_loop: >IDK:62TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
(...pre-exec...) = ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
TRACE (pid=10377):trace_loop: >IDK:11TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
(...pre-exec...) = ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
TRACE (pid=10377):trace_loop: >IDK:3TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
(...pre-exec...) = ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 36896768
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 36901248
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 37036416
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 37040128
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 1264893952
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)

--

I produces the trace on Debian Sid.
Comment 1 Victor Stinner 2011-04-25 23:55:31 UTC
Created attachment 271177 [details]
Testcase to demonstrate the bug (require static.c)
Comment 2 Victor Stinner 2011-04-25 23:56:08 UTC
Created attachment 271179 [details]
Dummy static binary writing 1 MB into stdout (used by sandbox_exec_bug.c)
Comment 3 SpanKY gentoo-dev 2012-03-06 18:55:28 UTC
this boils down to the forked parent that ptraces the child not closing all of its fd's.  so the parent has an open copy of the pipe still.  having the parent close all of its fd's fixes this test (nice debugging work btw).

i'll need to rework the logic so that sandbox itself doesn't need any fd's (it currently utilizes stderr for logging), and then the parent should be able to detach itself from all fd's.
Comment 4 SpanKY gentoo-dev 2012-07-03 18:50:23 UTC
i've got this fixed locally ... just need to iron out the debug fallout (current code writes to stderr), and it should be good to go
Comment 5 Mike Gilbert gentoo-dev 2012-09-29 18:17:33 UTC
@python: Arfrever informs me that this bug affects the test suite of python-3.3.0. FEATURES="test -sandbox -usersandbox" is a workaround.
Comment 6 Zac Medico gentoo-dev 2012-10-25 20:29:41 UTC
(In reply to comment #5)
> @python: Arfrever informs me that this bug affects the test suite of
> python-3.3.0. FEATURES="test -sandbox -usersandbox" is a workaround.

It also affects portage test cases after recent ctypes additions in the master branch. This triggers it:

  sandbox python3.3 pym/portage/tests/runTests \
    pym/portage/tests/emerge/test_simple.py

It hands in popen while running ldconfig -p.
Comment 7 Mike Gilbert gentoo-dev 2012-12-07 17:28:16 UTC
This is blocking python3.3 from being unmasked, so it would be nice to have a fix for this.
Comment 8 Tim Harder gentoo-dev 2013-01-18 17:26:39 UTC
*** Bug 452796 has been marked as a duplicate of this bug. ***
Comment 9 Dirkjan Ochtman gentoo-dev 2013-02-07 20:22:49 UTC
vapier, can you please move on this? There's a bunch of stuff blocked on this, so it would be nice if you can release your fix.
Comment 10 SpanKY gentoo-dev 2013-03-23 21:43:30 UTC
sandbox-2.6-r1 has a backport of the fix