Skip to content

Conversation

@dtrudg
Copy link
Member

@dtrudg dtrudg commented May 5, 2022

Description of the Pull Request (PR):

The experimental --sif-fuse code was attempting to pass the boolean that controls whether starter spawns the CleanupHost process, for unmounting the FUSE SIF mount, in the starter config structure.

The starter config structure is setup from the Go engine 'prepare' code, which runs in stage1 after the point at which CleanupHost is
spawned from the starter C code... so the boolean was never true.

Unfortunately, all the tests we have were passing, because due to a bad negation in an if statement, the CleanupHost process
was always executed.

Switch to using an env var (CLEANUP_HOST) to control whether the CleanupHost process is spawned by starter. This is the right way to control starter behavior that needs to occur before 'prepare' in stage1. It's the same approach used to control whether the overlay module is loaded via LOAD_OVERLAY_MODULE.

While we are at it, ensure a CleanupHost process is never run in setuid mode. We don't support this yet, and if support is added we need to pay attention to permanent priv drop etc.

Add a bit more debug logging so it's easier to see what's going on.

This fixes or addresses the following GitHub issues:

Before submitting a PR, make sure you have done the following:

@dtrudg dtrudg added the bug Something isn't working label May 5, 2022
@dtrudg dtrudg added this to the SingularityCE 3.10 milestone May 5, 2022
@dtrudg dtrudg self-assigned this May 5, 2022
@dtrudg dtrudg force-pushed the issue777 branch 3 times, most recently from 7267cc6 to 633d592 Compare May 5, 2022 20:27
The experimental `--sif-fuse` code was attempting to pass the boolean
that controls whether starter spawns the CleanupHost process, for
unmounting the FUSE SIF mount, in the starter config structure.

The starter config structure is setup from the Go engine 'prepare'
code, which runs in stage1 *after* the point at which CleanupHost is
spawned from the starter C code... so the boolean was never true.

Unfortunately, all the tests we have were passing, because due to a
bad negation in an if statement, the `CleanupHost` process
was *always* executed.

Switch to using an env var (`CLEANUP_HOST`) to control whether the
`CleanupHost` process is spawned by starter. This is the right way to
control starter behavior that needs to occur before 'prepare' in
stage1. It's the same approach used to control whether the overlay
module is loaded via `LOAD_OVERLAY_MODULE`.

While we are at it, ensure a `CleanupHost` process is never run in
setuid mode. We don't support this yet, and if support is added we
need to pay attention to permanent priv drop etc.

Add a bit more debug logging so it's easier to see what's going on.

Fixes sylabs#777
@dtrudg dtrudg marked this pull request as ready for review May 5, 2022 20:52
@dtrudg dtrudg merged commit 9bd92c8 into sylabs:master May 5, 2022
@dtrudg dtrudg deleted the issue777 branch May 5, 2022 21:03
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

Successfully merging this pull request may close these issues.

Starter cleanupHost flag is not being set / consumed properly

2 participants