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

runc delete -f: fix for cg v1 + paused container #3217

Merged
merged 1 commit into from
Sep 20, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions libcontainer/container_linux.go
Original file line number Diff line number Diff line change
Expand Up @@ -393,6 +393,14 @@ func (c *linuxContainer) Signal(s os.Signal, all bool) error {
if err := c.initProcess.signal(s); err != nil {
return fmt.Errorf("unable to signal init: %w", err)
}
if status == Paused {
// For cgroup v1, killing a process in a frozen cgroup
// does nothing until it's thawed. Only thaw the cgroup
// for SIGKILL.
if s, ok := s.(unix.Signal); ok && s == unix.SIGKILL {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would've been nice to check if the cgroup manager is v1 or v2 here, but still LGTM.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are going to use cgroup.kill for v2 and hybrid hierarchies, this code is just to fix the issue

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I get that -- my point is more that it would've been nice if we didn't thaw the cgroup unless we really had to.

_ = c.cgroupManager.Freeze(configs.Thawed)
}
}
return nil
}
return ErrNotRunning
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't tried, but what happens currently if -f is used and it's not running? (thinking: -f should ignore the case and just proceed?) I see we have a special case for all

Copy link
Member

@cyphar cyphar Sep 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic for not allowing kill even if you force it is that on paper you could trick runc to kill an arbitrary process. I think an actual attack that uses this is a bit theoretical but shrug. You can't signal a process that doesn't exist.

Expand Down
10 changes: 10 additions & 0 deletions tests/integration/delete.bats
Original file line number Diff line number Diff line change
Expand Up @@ -50,6 +50,16 @@ function teardown() {
[ "$status" -eq 0 ]
}

@test "runc delete --force [paused container]" {
runc run -d --console-socket "$CONSOLE_SOCKET" ct1
[ "$status" -eq 0 ]
testcontainer ct1 running

runc pause ct1
runc delete --force ct1
[ "$status" -eq 0 ]
}

@test "runc delete --force in cgroupv1 with subcgroups" {
requires cgroups_v1 root cgroupns
set_cgroups_path
Expand Down