Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test suite fails on Fedora #118

Open
DemiMarie opened this issue Feb 13, 2022 · 2 comments
Open

Test suite fails on Fedora #118

DemiMarie opened this issue Feb 13, 2022 · 2 comments
Labels
bug Something isn't working

Comments

@DemiMarie
Copy link
Contributor

The test suite fails on Fedora. Build script and log output attached.
log.txt
build.txt

copybara-service bot pushed a commit that referenced this issue Feb 14, 2022
This adds a first basic test to be run using GitHub Actions on push and pull
request for the CMake build (internally we run everything on Bazel/Blaze).

The Ubuntu runners are implemented as full VMs, so we can run tests directly.

In order to run Sandboxed API/Sandbox2 tests inside a container, it must be
started as privileged, unconfined and retain its capabilities.
Since GitHub does not support modifying the Docker invocation for container
based workflows, we need to manually run the `docker` command.

Until #118 is fixed, this change makes GitHub ignore the test failure on
Fedora.

PiperOrigin-RevId: 428485354
Change-Id: I6b55c5441c4c27b018d19498d2296c7d3da65846
@cblichmann cblichmann added the bug Something isn't working label Feb 14, 2022
@cblichmann
Copy link
Member

I need to debug this a bit, but a recent run of the Fedora build behaves (AFAICT) the same.
Looking at sandboxed_api/sandbox2/stack_trace.cc:142, we're probably just missing /lib and /lib64 (although on Fedora, those are symlinks).

So maybe we should revisit the statement that we don't need to parse /proc/<pid>/maps and/or /proc/<pid>/exe.

@DemiMarie
Copy link
Contributor Author

I need to debug this a bit, but a recent run of the Fedora build behaves (AFAICT) the same. Looking at sandboxed_api/sandbox2/stack_trace.cc:142, we're probably just missing /lib and /lib64 (although on Fedora, those are symlinks).

/usr/lib64 is the main one.

So maybe we should revisit the statement that we don't need to parse /proc/<pid>/maps and/or /proc/<pid>/exe.

I don’t think parsing those is a good idea if it means the sandboxed process needs access to /proc, as /proc has been a source of kernel vulnerabilities in the past. If the parent process needs to parse /proc/self/maps or /proc/self/exe that is fine. Parsing the child process’s /proc/<pid>/{maps,exe} should be fine provided that the parsing code is robust against malicious input.

copybara-service bot pushed a commit that referenced this issue Mar 28, 2022
This fixes the main issue (#118) with stack traces on Fedora, which uses a
`/lib64` and `/usr/lib64`.

PiperOrigin-RevId: 437717858
Change-Id: I6986aa84c2be57ae1d9f8d0cb9b508768d27f1c1
oshogbo pushed a commit to oshogbo/sandboxed-api that referenced this issue Mar 29, 2022
This fixes the main issue (google#118) with stack traces on Fedora, which uses a
`/lib64` and `/usr/lib64`.

PiperOrigin-RevId: 437717858
Change-Id: I6986aa84c2be57ae1d9f8d0cb9b508768d27f1c1
happyCoder92 pushed a commit that referenced this issue May 4, 2022
This adds a first basic test to be run using GitHub Actions on push and pull
request for the CMake build (internally we run everything on Bazel/Blaze).

The Ubuntu runners are implemented as full VMs, so we can run tests directly.

In order to run Sandboxed API/Sandbox2 tests inside a container, it must be
started as privileged, unconfined and retain its capabilities.
Since GitHub does not support modifying the Docker invocation for container
based workflows, we need to manually run the `docker` command.

Until #118 is fixed, this change makes GitHub ignore the test failure on
Fedora.

PiperOrigin-RevId: 428485354
Change-Id: I6b55c5441c4c27b018d19498d2296c7d3da65846
happyCoder92 pushed a commit that referenced this issue May 4, 2022
This fixes the main issue (#118) with stack traces on Fedora, which uses a
`/lib64` and `/usr/lib64`.

PiperOrigin-RevId: 437717858
Change-Id: I6986aa84c2be57ae1d9f8d0cb9b508768d27f1c1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants