Summary: | sys-apps/sandbox: blocks programs which call open("/proc/sys...", O_RDONLY) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Thomas Deutschmann (RETIRED) <whissi> |
Component: | Sandbox | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 589378 |
Description
Thomas Deutschmann (RETIRED)
2016-08-30 10:57:36 UTC
> This raises the question why syscall() works around the problem. Maybe a bug
> in sys-apps/sandbox with open()?
It's explained in the jemalloc issue #443 - sandbox's open() replacement uses jemalloc's malloc() replacement which triggers some jemalloc initialization routine that should not be called at that point.
I see two way to fix this: change jemalloc and similar custom memory allocators to avoid sandbox's allocations in problem areas, or change sandbox to always use the glibc malloc instead of allowing overrides from sandboxed libraries.
jemalloc upstream has now declined to do anything to workaround that issue saying it is a bootstrap issue and only affects people who hook into "open()": https://github.com/jemalloc/jemalloc/issues/443#issuecomment-245357510 Can the sandbox team please answer if this is a bug within sandbox's hooking or not? If it's not a bug we need a way to workaround that issue in ebuilds. I.e. ship jemalloc with my patch applied (I am not sure if syscall(SYS_OPEN...) instead of open() has performance impact)... Upstream has changed its mind and committed https://github.com/jemalloc/jemalloc/commit/c443b67561891ae68d688daf5f8ce37820cdba2b I'll shortly bump dev-libs/jemalloc with this cherry-picked commit. > commit 7565f43fc1c544625d153f510b950f9f9bf6e848
> Author: Thomas Deutschmann
> Date: Tue Nov 1 16:22:38 2016 +0100
>
> dev-libs/jemalloc: Patch added to fix an issue with sys-apps/sandbox
>
> Cherry picked commit c443b67561 [Link 1] which fixes an issue which
> prevented any jemalloc-enabled application from running through
> sys-apps/sandbox (typical use case is emerge with FEATURES=sandbox and
> FEATURES=test).
>
> Cherry picked commit 3c8c3e9e9b [Link 2] which fixes a leaked file
> descriptor.
>
> Link 1: https://github.com/jemalloc/jemalloc/commit/c443b67561891ae68d688daf5f8ce37820cdba2b
> Link 2: https://github.com/jemalloc/jemalloc/commit/3c8c3e9e9b59b6e34a222816a05f0a01a68919b3
> Gentoo-Bug: https://bugs.gentoo.org/592420
>
> Package-Manager: portage-2.3.2
there is 0 good reason why an allocator should be screwing with global system settings like /proc/sys/. i run a program as non-root and it does one thing, but if i run it as root, it now modifies global settings ? that's brain dead. the reason syscall() works is because the default sandbox mode is to run in process and hook C library calls. it makes things faster. however, sandbox can run in ptrace mode in which case it would catch & reject these sort of things. atm we only do it for static binaries, but that's not guaranteed to stay that way. so ignoring the open hooking issue, sandbox *should* be catching attempts to screw with /proc/sys/ and throwing a sandbox violation. |