starred/act

Fork 0

mirror of https://github.com/nektos/act.git synced 2026-04-26 01:15:51 +03:00

[PR #1682] [CLOSED] Draft: LXC support for self-hosted runners #2068

New issue

Closed

opened 2026-03-01 21:53:52 +03:00 by kerem · 0 comments

kerem commented

2026-03-01 21:53:52 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/nektos/act/pull/1682
Author: @earl-warren
Created: 3/16/2023
Status: ❌ Closed

Base: master ← Head: wip-github-lxc

📝 Commits (6)

c7f0532 add stopHostEnvironment to tear down the LXC container
9c95665 shell script to start the LXC container
3ee8456 create and destroy a LXC container
fbad698 run commands with lxc-attach
643a462 expose additional devices for docker & libvirt to work
2ccb312 install node 16 & git for checkout to work

📊 Changes

4 files changed (+186 additions, -9 deletions)

View changed files

📝 pkg/container/executions_environment.go (+2 -0)
📝 pkg/container/host_environment.go (+24 -5)
📝 pkg/container/linux_container_environment_extensions.go (+9 -2)
📝 pkg/runner/run_context.go (+151 -2)

📄 Description

Description

The LXC support for self-hosted runners is used to run tests that do not fit the constraints imposed by the docker backend such as having a systemd capable environment.

It creates a container from scratch on every run. If the tests accidentally damage essential services such as the ssh server, it will not have any impact on the host running the LXC container. If the same accident happens without the isolation provided by the LXC container, the host itself will be damaged. The LXC support provides a robust isolation for each job in the workflows, which the self-hosted platform does not.

Implementation details

It is roughly the equivalent of doing the following:

Creating a LXC container (with lxc-create)
Running the commands in the container (with lxc-attach)
Destroying the LXC container (with lxc-destroy)

This is inherently insecure, in the same way the self-hosted platform is. Hardening LXC containers is possible but it makes them no more useful than docker containers.

FAQ

Why not run LXC inside a Docker container? Because it does not work. Although it could probably be hacked, that would not be more than that.
Why not run the LXC logic from the sef-hosted platform? Because it would require significant work and LXC knowledge from each ACT user. Instead they only have to care for their own tests, not to setup and teardown well isolated LXC containers.
Why not run the LXC containers as unprivileged to improve security? Because it does not work with most templates. Given the restrictions it imposes, the user is better of using Docker.
Why is apparmor disabled? Because it cannot be configured to allow essential operations such as mounting file systems

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/nektos/act/pull/1682 **Author:** [@earl-warren](https://github.com/earl-warren) **Created:** 3/16/2023 **Status:** ❌ Closed **Base:** `master` ← **Head:** `wip-github-lxc` --- ### 📝 Commits (6) - [`c7f0532`](https://github.com/nektos/act/commit/c7f05329f734889209520b668b289dba22002d59) add stopHostEnvironment to tear down the LXC container - [`9c95665`](https://github.com/nektos/act/commit/9c956651f2aabcc77a01cea812417c35a17d1476) shell script to start the LXC container - [`3ee8456`](https://github.com/nektos/act/commit/3ee8456ce6d2c40e7d399f470afb6863c4c1c276) create and destroy a LXC container - [`fbad698`](https://github.com/nektos/act/commit/fbad698c30dd37928f130f831375d081966d925d) run commands with lxc-attach - [`643a462`](https://github.com/nektos/act/commit/643a4623307ef982ff4ea394786ce3ba0185dadb) expose additional devices for docker & libvirt to work - [`2ccb312`](https://github.com/nektos/act/commit/2ccb31234669f458fa5b70e737f6a3601033d130) install node 16 & git for checkout to work ### 📊 Changes **4 files changed** (+186 additions, -9 deletions) <details> <summary>View changed files</summary> 📝 `pkg/container/executions_environment.go` (+2 -0) 📝 `pkg/container/host_environment.go` (+24 -5) 📝 `pkg/container/linux_container_environment_extensions.go` (+9 -2) 📝 `pkg/runner/run_context.go` (+151 -2) </details> ### 📄 Description ## Description The [LXC](https://linuxcontainers.org/) support for self-hosted runners is used to **run tests that do not fit the constraints imposed by the docker backend** such as having a systemd capable environment. It creates a container from scratch on every run. If the tests accidentally damage essential services such as the ssh server, it will not have any impact on the host running the LXC container. If the same accident happens without the isolation provided by the LXC container, the host itself will be damaged. The **LXC support provides a robust isolation for each job in the workflows, which the self-hosted platform does not.** ## Implementation details It is roughly the equivalent of doing the following: * Creating a LXC container (with lxc-create) * Running the commands in the container (with lxc-attach) * Destroying the LXC container (with lxc-destroy) This is inherently insecure, in the same way the self-hosted platform is. Hardening LXC containers is possible but it makes them no more useful than docker containers. ## FAQ * **Why not run LXC inside a Docker container?** Because [it does not work](https://github.com/woodpecker-ci/woodpecker/pull/1565#issuecomment-1413922298). Although it could probably be hacked, that would not be more than that. * **Why not run the LXC logic from the sef-hosted platform?** Because it would require significant work and LXC knowledge from each ACT user. Instead they only have to care for their own tests, not to setup and teardown well isolated LXC containers. * **Why not run the LXC containers as unprivileged to improve security?** Because it does not work with [most templates](https://linuxcontainers.org/lxc/getting-started/#creating-unprivileged-containers-as-a-user). Given the restrictions it imposes, the user is better of using Docker. * **Why is apparmor disabled?** Because it cannot be configured [to allow essential operations such as mounting file systems](https://discuss.linuxcontainers.org/t/what-does-security-nesting-true/7156/2) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

2026-03-01 21:53:52 +03:00

closed this issue
added the
pull-request
label

kerem referenced this issue

2026-03-01 21:54:39 +03:00

[PR #2068] [MERGED] build(deps): bump github.com/creack/pty from 1.1.18 to 1.1.20 #2255

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/act#2068

No description provided.

Rows
Columns