[PATCH 1/1] kas-container: add experimental support for run0

[Felix Moessbauer]

ISAR builds need to be executed in privileged mode. Currently,
kas-container uses sudo to start the container, but this is breaks
in environments that set the "no new privileges" flag (like the
VSCode shell). This can be solved by using run0 (which is a wrapper
around systemd-run) to let the init system directly start the
privileged workload (with PAM authentication and alike).

We now add experimental support for run0 to kas-container for targets
that conceptually support this (like the podman / docker execution).
We further add this as a fallback in case sudo is not installed.

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---
This has been tested with ISAR builds in a VSCode terminal.
As the execution model of run0 is fundamentally different than the
one of sudo, surprises are expected. Hence, we add a warning, that
this mode is still experimental.

Happy testing!
Felix

kas-container | 35 ++++++++++++++++++++++++++++++++---
1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/kas-container b/kas-container
index e8735884d..c46323238 100755
--- a/kas-container
+++ b/kas-container
@@ -64,7 +64,8 @@ usage()
printf "%b" "menu\t\t\tProvide configuration menu and trigger " \
"configured build.\n"
printf "%b" "\nOptional arguments:\n"
- printf "%b" "--isar\t\t\tUse kas-isar container to build Isar image.\n"
+ printf "%b" "--isar\t\t\tUse kas-isar container to build Isar image. To force\n"
+ printf "%b" " \t\t\tthe use of run0 over sudo, set KAS_SUDO_CMD=run0.\n"
printf "%b" "--with-loop-dev Pass a loop device to the " \
"container. Only required if\n"
printf "%b" "\t\t\tloop-mounting is used by recipes.\n"
@@ -117,6 +118,29 @@ trace()
"$@"
}

+prepare_sudo_cmd()
+{
+ if [ -z "${KAS_SUDO_CMD}" ]; then
+ # Try to auto-detect a container engine
+ if command -v sudo >/dev/null; then
+ KAS_SUDO_CMD="sudo"
+ elif command -v run0 >/dev/null; then
+ KAS_SUDO_CMD="run0"
+ else
+ fatal_error "No privileged executor found, need sudo or run0."
+ fi
+ fi
+
+ if [ "${KAS_SUDO_CMD}" = "sudo" ]; then
+ _KAS_SUDO_CMD="sudo --preserve-env"
+ elif [ "${KAS_SUDO_CMD}" = "run0" ]; then
+ _KAS_SUDO_CMD="run0 --background= --unit=kas-container@$$"
+ warning "Running under run0 is experimental"
+ else
+ fatal_error "Unsupported KAS_SUDO_CMD ('${KAS_SUDO_CMD}'), use sudo or run0."
+ fi
+}
+
enable_isar_mode()
{
if [ -n "${ISAR_MODE}" ]; then
@@ -127,16 +151,17 @@ enable_isar_mode()
KAS_CONTAINER_IMAGE_NAME_DEFAULT="kas-isar"
KAS_ISAR_ARGS="--privileged"

+ prepare_sudo_cmd
if [ "${KAS_CONTAINER_ENGINE}" = "podman" ]; then
# sudo is needed for a privileged podman container
- KAS_CONTAINER_COMMAND="sudo --preserve-env ${KAS_CONTAINER_COMMAND}"
+ KAS_CONTAINER_COMMAND="${_KAS_SUDO_CMD} ${KAS_CONTAINER_COMMAND}"
# preserved user PATH may lack sbin needed by privileged podman
export PATH="${PATH}:/usr/sbin"
elif [ "${KAS_DOCKER_ROOTLESS}" = "1" ]; then
export DOCKER_HOST="${DOCKER_HOST:-unix:///var/run/docker.sock}"
debug "kas-isar does not support rootless docker. Using system docker"
# force use of well-known system docker socket
- KAS_CONTAINER_COMMAND="sudo --preserve-env ${KAS_CONTAINER_COMMAND}"
+ KAS_CONTAINER_COMMAND="${_KAS_SUDO_CMD} ${KAS_CONTAINER_COMMAND}"
KAS_DOCKER_ROOTLESS=0
fi
}
@@ -339,6 +364,10 @@ while [ $# -gt 0 ]; do
if [ "$(id -u)" -eq 0 ]; then
fatal_error "loop device not available!"
fi
+ prepare_sudo_cmd
+ if [ "$KAS_SUDO_CMD" != "sudo" ]; then
+ fatal_error "--with-loop-dev requires sudo for device setup."
+ fi
sudo_command="/sbin/losetup -f"
sudo_message="[sudo] enter password to setup loop"
sudo_message="$sudo_message devices by calling"
--
2.50.0

[Michael Adler]

> Happy testing!

Thanks ;)

Tested-by: Michael Adler <michae...@siemens.com>

KR, Michael

--
Michael Adler

Siemens AG
Technology
Connectivity & Edge
Open Source Embedded Systems
FT RPD CED OES-DE
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann
Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive
Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese;
Registered offices: Berlin and Munich, Germany; Commercial registries:
Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

[Jörg Sommer]

'Felix Moessbauer' via kas-devel schrieb am Fr 18. Jul, 16:23 (+0200):

> ISAR builds need to be executed in privileged mode. Currently,
> kas-container uses sudo to start the container, but this is breaks

Is the word “is” at the end wrong?

> in environments that set the "no new privileges" flag (like the
> VSCode shell). This can be solved by using run0 (which is a wrapper

Regards Jörg
--
Navimatix GmbH T: 03641 - 327 99 0
Tatzendpromenade 2 F: 03641 - 526 306
07745 Jena www.navimatix.de

Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480

[MOESSBAUER, Felix]

On Tue, 2025-07-29 at 14:07 +0200, Jörg Sommer wrote:
> 'Felix Moessbauer' via kas-devel schrieb am Fr 18. Jul, 16:23
> (+0200):
> > ISAR builds need to be executed in privileged mode. Currently,
> > kas-container uses sudo to start the container, but this is breaks
>
> Is the word “is” at the end wrong?

Yes, that's wrong. Also the section regarding PAM is not 100% correct,
as run0 relies on polkit, which internally goes through PAM for
authentication. I'll fix it in a v2, once I get more reviews.

Did you already check this patch?

Best regards,
Felix


--
Siemens AG
Linux Expert Center

[Jörg Sommer]

'Felix Moessbauer' via kas-devel schrieb am Fr 18. Jul, 16:23 (+0200):

Maybe this is a little more compact:

case "$KAS_SUDO_CMD" in
sudo) _KAS_SUDO_CMD="sudo --preserve-env";;
run0) _KAS_SUDO_CMD="run0 --background= --unit=kas-container@$$";;
*) fatal_error "Unsupported KAS_SUDO_CMD ('${KAS_SUDO_CMD}'), use sudo or run0.";;
esac

> + prepare_sudo_cmd

I didn't test it, but wouldn't this require sudo or run0 are installed, even
if `KAS_CONTAINER_ENGINE = docker` and `KAS_DOCKER_ROOTLESS = 0`?

> if [ "${KAS_CONTAINER_ENGINE}" = "podman" ]; then
> # sudo is needed for a privileged podman container
> - KAS_CONTAINER_COMMAND="sudo --preserve-env ${KAS_CONTAINER_COMMAND}"
> + KAS_CONTAINER_COMMAND="${_KAS_SUDO_CMD} ${KAS_CONTAINER_COMMAND}"
> # preserved user PATH may lack sbin needed by privileged podman
> export PATH="${PATH}:/usr/sbin"
> elif [ "${KAS_DOCKER_ROOTLESS}" = "1" ]; then
> export DOCKER_HOST="${DOCKER_HOST:-unix:///var/run/docker.sock}"
> debug "kas-isar does not support rootless docker. Using system docker"
> # force use of well-known system docker socket
> - KAS_CONTAINER_COMMAND="sudo --preserve-env ${KAS_CONTAINER_COMMAND}"
> + KAS_CONTAINER_COMMAND="${_KAS_SUDO_CMD} ${KAS_CONTAINER_COMMAND}"
> KAS_DOCKER_ROOTLESS=0
> fi
> }

> @@ -339,6 +364,10 @@ while [ $# -gt 0 ]; do
> if [ "$(id -u)" -eq 0 ]; then
> fatal_error "loop device not available!"
> fi
> + prepare_sudo_cmd
> + if [ "$KAS_SUDO_CMD" != "sudo" ]; then
> + fatal_error "--with-loop-dev requires sudo for device setup."
> + fi

I don't know if you like the style

[ "$KAS_SUDO_CMD" = "sudo" ] || fatal_error "--with-loop-dev requires sudo for device setup."

And maybe use ' instead of " to ensure no interpolation happens.


I have no real use case to test the code. But as far as I can see, it looks
sensible.

[MOESSBAUER, Felix]

True, I'll change it accordingly.

>
> > + prepare_sudo_cmd
>
> I didn't test it, but wouldn't this require sudo or run0 are
> installed, even
> if `KAS_CONTAINER_ENGINE = docker` and `KAS_DOCKER_ROOTLESS = 0`?

Good catch!

We have shellcheck, but it also does not hurt :)

>
>
> I have no real use case to test the code. But as far as I can see, it
> looks
> sensible.

You are probably a Yocto user. Then this patch should not be relevant
for you. Anyways, many thanks for the detailed review and for spotting
the error.

[Felix Moessbauer]

ISAR builds need to be executed in privileged mode. Currently,

kas-container uses sudo to start the container, but this breaks in

environments that set the "no new privileges" flag (like the VSCode

shell). This can be solved by using run0 (which is a wrapper around
systemd-run) to let the init system directly start the privileged

workload (with PolicyKit based authentication).

We now add experimental support for run0 to kas-container for targets

that support this (like the podman / docker execution). We further add

this as a fallback in case sudo is not installed.

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---

Changes since v1:

- do not require sudo on --isar on standard docker (non rootless)
- make implementation more compact
- improve commit message (PolicyKit instead of PAM, typos)

kas-container | 32 +++++++++++++++++++++++++++++---
1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/kas-container b/kas-container
index e8735884d..6dacc6a26 100755

--- a/kas-container
+++ b/kas-container
@@ -64,7 +64,8 @@ usage()
printf "%b" "menu\t\t\tProvide configuration menu and trigger " \
"configured build.\n"
printf "%b" "\nOptional arguments:\n"
- printf "%b" "--isar\t\t\tUse kas-isar container to build Isar image.\n"
+ printf "%b" "--isar\t\t\tUse kas-isar container to build Isar image. To force\n"
+ printf "%b" " \t\t\tthe use of run0 over sudo, set KAS_SUDO_CMD=run0.\n"
printf "%b" "--with-loop-dev Pass a loop device to the " \
"container. Only required if\n"
printf "%b" "\t\t\tloop-mounting is used by recipes.\n"

@@ -117,6 +118,26 @@ trace()

"$@"
}

+prepare_sudo_cmd()
+{
+ if [ -z "${KAS_SUDO_CMD}" ]; then

+ # Try to auto-detect a privileged executor

+ if command -v sudo >/dev/null; then
+ KAS_SUDO_CMD="sudo"
+ elif command -v run0 >/dev/null; then
+ KAS_SUDO_CMD="run0"
+ else
+ fatal_error "No privileged executor found, need sudo or run0."
+ fi
+ fi
+

+ case "$KAS_SUDO_CMD" in
+ sudo) _KAS_SUDO_CMD="sudo --preserve-env";;
+ run0) _KAS_SUDO_CMD="run0 --background= --unit=kas-container@$$";;
+ *) fatal_error "Unsupported KAS_SUDO_CMD ('${KAS_SUDO_CMD}'), use sudo or run0.";;
+ esac

+}
+
enable_isar_mode()
{
if [ -n "${ISAR_MODE}" ]; then

@@ -128,15 +149,17 @@ enable_isar_mode()
KAS_ISAR_ARGS="--privileged"

if [ "${KAS_CONTAINER_ENGINE}" = "podman" ]; then

+ prepare_sudo_cmd

# sudo is needed for a privileged podman container
- KAS_CONTAINER_COMMAND="sudo --preserve-env ${KAS_CONTAINER_COMMAND}"
+ KAS_CONTAINER_COMMAND="${_KAS_SUDO_CMD} ${KAS_CONTAINER_COMMAND}"
# preserved user PATH may lack sbin needed by privileged podman
export PATH="${PATH}:/usr/sbin"
elif [ "${KAS_DOCKER_ROOTLESS}" = "1" ]; then

+ prepare_sudo_cmd
export DOCKER_HOST="${DOCKER_HOST:-unix:///var/run/docker.sock}"

debug "kas-isar does not support rootless docker. Using system docker"
# force use of well-known system docker socket
- KAS_CONTAINER_COMMAND="sudo --preserve-env ${KAS_CONTAINER_COMMAND}"
+ KAS_CONTAINER_COMMAND="${_KAS_SUDO_CMD} ${KAS_CONTAINER_COMMAND}"
KAS_DOCKER_ROOTLESS=0
fi
}

@@ -339,6 +362,9 @@ while [ $# -gt 0 ]; do

if [ "$(id -u)" -eq 0 ]; then
fatal_error "loop device not available!"
fi
+ prepare_sudo_cmd

+ [ "$KAS_SUDO_CMD" = "sudo" ] || fatal_error '--with-loop-dev requires sudo for device setup.'
+

[Jan Kiszka]

On 29.07.25 16:31, 'Felix Moessbauer' via kas-devel wrote:
> ISAR builds need to be executed in privileged mode. Currently,
> kas-container uses sudo to start the container, but this breaks in
> environments that set the "no new privileges" flag (like the VSCode
> shell). This can be solved by using run0 (which is a wrapper around
> systemd-run) to let the init system directly start the privileged
> workload (with PolicyKit based authentication).
>
> We now add experimental support for run0 to kas-container for targets

What exactly makes this "experimental"? Are there known limitations /
issues?

So, the target environment that needs run0 will for sure lack sudo? I'm
just wondering if the preference of sudo over run0 is intentional.

We do "if then fi" elsewhere, why not here? Would also make the line a
bit shorter.

> sudo_command="/sbin/losetup -f"
> sudo_message="[sudo] enter password to setup loop"
> sudo_message="$sudo_message devices by calling"

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[MOESSBAUER, Felix]

On Thu, 2025-08-07 at 18:18 +0200, Jan Kiszka wrote:
> On 29.07.25 16:31, 'Felix Moessbauer' via kas-devel wrote:
> > ISAR builds need to be executed in privileged mode. Currently,
> > kas-container uses sudo to start the container, but this breaks in
> > environments that set the "no new privileges" flag (like the VSCode
> > shell). This can be solved by using run0 (which is a wrapper around
> > systemd-run) to let the init system directly start the privileged
> > workload (with PolicyKit based authentication).
> >
> > We now add experimental support for run0 to kas-container for
> > targets
>
> What exactly makes this "experimental"? Are there known limitations /
> issues?

One limitation is the unsupported loopback setup. I further only tested
this on podman, not docker (the tricky to test docker-rootless -> use
system docker case).

Apart from that, we cannot preserve the environment, so there might be
surprises. The environment parts handled by kas (like proxy, NETRC,
...) properly works, though, as the corresponding values are explicitly
added as runtime startup args.

No, I'm pretty sure sudo will stay for quite some time. However, there
are already cases where the current environment is not able to run sudo
(due to the "no new privileges" flag, e.g. in a VSCode shell). In this
case, run0 can be used, as it behaves fundamentally different (i.e. no
setuid binary, but startup via the init system).

run0 on the other hand is still a bit clumsy to use, as polkit does not
cache credentials - and by that prompts the user on every run0 run.

Once the other points are clarified, I'll switch this over to if / else
in a v3.

Felix

>
> >   sudo_command="/sbin/losetup -f"
> >   sudo_message="[sudo] enter password to
> > setup loop"
> >   sudo_message="$sudo_message devices by
> > calling"
>
> Jan

--

[Jan Kiszka]

On 08.08.25 09:13, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> On Thu, 2025-08-07 at 18:18 +0200, Jan Kiszka wrote:
>> On 29.07.25 16:31, 'Felix Moessbauer' via kas-devel wrote:
>>> ISAR builds need to be executed in privileged mode. Currently,
>>> kas-container uses sudo to start the container, but this breaks in
>>> environments that set the "no new privileges" flag (like the VSCode
>>> shell). This can be solved by using run0 (which is a wrapper around
>>> systemd-run) to let the init system directly start the privileged
>>> workload (with PolicyKit based authentication).
>>>
>>> We now add experimental support for run0 to kas-container for
>>> targets
>>
>> What exactly makes this "experimental"? Are there known limitations /
>> issues?
>
> One limitation is the unsupported loopback setup. I further only tested
> this on podman, not docker (the tricky to test docker-rootless -> use
> system docker case).
>
> Apart from that, we cannot preserve the environment, so there might be
> surprises. The environment parts handled by kas (like proxy, NETRC,
> ...) properly works, though, as the corresponding values are explicitly
> added as runtime startup args.
>

This should be documented in kas, not only here.

So this is intentionally opt-in. Needs to be documented as well, along
with KAS_SUDO_CMD as control variable.

Jan

[Felix Moessbauer]

Changes since v2:

- document run0 limitations and KAS_SUDO_CMD variable
- change codestyle according to review comments (if/else)
- p2: refactor isar clean execution to only call sudo once
- p3: add support for run0 in kas itself (optional)

Changes since v1:

- do not require sudo on --isar on standard docker (non rootless)
- make implementation more compact
- improve commit message (PolicyKit instead of PAM, typos)

Best regards,
Felix

Felix Moessbauer (3):
kas-container: add partial support for run0
refactor(clean): call sudo only once in ISAR mode
kas(isar): add support to clean with run0

docs/command-line/environment-variables.inc | 8 ++++
kas-container | 33 ++++++++++++--
kas/plugins/clean.py | 49 +++++++++++++++++----
3 files changed, 79 insertions(+), 11 deletions(-)

--
2.50.1

[Felix Moessbauer]

Previously, we called sudo per directory that should be removed.
Depending on the sudo configuration, this might ask the user each and
every time to authenticate and grant permission. We now change that to
just a single sudo call which removes all dirs at once.

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---

kas/plugins/clean.py | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/kas/plugins/clean.py b/kas/plugins/clean.py
index 4ca4e46f1..6eb39c630 100644
--- a/kas/plugins/clean.py
+++ b/kas/plugins/clean.py
@@ -91,18 +91,26 @@ class Clean():
if args.dry_run:
logging.warning('Dry run, not removing anything')
tmpdirs = Path(ctx.build_dir).glob('tmp*')
+
+ dirs_to_remove = []
for tmpdir in tmpdirs:
logging.info(f'Removing {tmpdir}')
- if args.dry_run:
- continue
if build_system == 'isar':
- clean_args = [
- 'sudo', '--prompt', '[sudo] enter password for %U '
- f'to clean ISAR artifacts in {tmpdir}',
- 'rm', '-rf', str(tmpdir)]
- subprocess.check_call(clean_args)
+ dirs_to_remove.append(tmpdir)
else:
- shutil.rmtree(tmpdir)
+ if not args.dry_run:
+ shutil.rmtree(tmpdir)
+
+ if len(dirs_to_remove) == 0:
+ return
+
+ clean_args = ['sudo', '--prompt', '[sudo] enter password for %U '
+ 'to clean ISAR artifacts']
+ clean_args.extend(['rm', '-rf'])
+ clean_args.extend([p.as_posix() for p in dirs_to_remove])
+ logging.debug(' '.join(clean_args))
+ if not args.dry_run:
+ subprocess.check_call(clean_args)

@staticmethod
def clear_dir_content(directory):
--
2.50.1

[Felix Moessbauer]

In isar mode, a privileged executor is needed to remove the tmpdir(s).
As of now, isar requires sudo, but we already prepare the code to be
run0 compatible as well. By that, we can re-use the KAS_SUDO_CMD
environment variable.

Note, that the variable is not forwarded into the container, as the
tooling inside the container is independent from the outside (e.g.
outside you might want to use run0, while inside you have to use
whatever is provided by the container).

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---

docs/command-line/environment-variables.inc | 5 ++--
kas/plugins/clean.py | 29 +++++++++++++++++++--
2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/docs/command-line/environment-variables.inc b/docs/command-line/environment-variables.inc
index b4ea240e8..ad1f04bf4 100644
--- a/docs/command-line/environment-variables.inc
+++ b/docs/command-line/environment-variables.inc
@@ -201,11 +201,12 @@ overwritten using the ``env`` section of the config file.
| | auto-detected (preference: docker). |
+--------------------------+--------------------------------------------------+
| ``KAS_SUDO_CMD`` | Explicitly set the sudo command (either ``sudo`` |
-| (C) | or ``run0``) for operations that require higher |
+| (C,K) | or ``run0``) for operations that require higher |
| | privileges. If not set, this is auto-detected |
| | (preference: ``sudo``). Note, that ``run0`` does |
| | not preserve the environment and cannot setup |
-| | loopback devices. |
+| | loopback devices. The `KAS_SUDO_CMD` needs to be |
+| | explicitly set inside the container. |
+--------------------------+--------------------------------------------------+

.. |aws_cred| replace:: ``AWS_ROLE_ARN``
diff --git a/kas/plugins/clean.py b/kas/plugins/clean.py
index 6eb39c630..5a83b4894 100644
--- a/kas/plugins/clean.py
+++ b/kas/plugins/clean.py
@@ -104,8 +104,7 @@ class Clean():
if len(dirs_to_remove) == 0:
return

- clean_args = ['sudo', '--prompt', '[sudo] enter password for %U '
- 'to clean ISAR artifacts']
+ clean_args = Clean.get_sudo_cmd('clean ISAR artifacts')

clean_args.extend(['rm', '-rf'])

clean_args.extend([p.as_posix() for p in dirs_to_remove])

logging.debug(' '.join(clean_args))
@@ -123,6 +122,32 @@ class Clean():
else:
item.unlink()

+ @staticmethod
+ def get_sudo_cmd(reason):
+ """
+ Resolve which privileged executor shall be used (prefer sudo).
+ If supported by the executor, the reason is added to the prompt.
+ """
+ sudo_cmd = os.environ.get('KAS_SUDO_CMD')
+ if not sudo_cmd:
+ if shutil.which('sudo'):
+ sudo_cmd = 'sudo'
+ elif shutil.which('run0'):
+ sudo_cmd = 'run0'
+ else:
+ raise KasUserError('No privileged executor found, '
+ 'need sudo or run0.')
+
+ if sudo_cmd == 'sudo':
+ prompt = '[sudo] enter password for %U'
+ if reason:
+ prompt += f' to {reason}'
+ return [sudo_cmd, '--prompt', prompt]
+ elif sudo_cmd == 'run0':
+ return [sudo_cmd, '--background=', '--unit=kas@$$']
+ else:
+ raise KasUserError('Unsupported KAS_SUDO_CMD, use sudo or run0.')
+

class CleanSstate(Clean):
"""
--
2.50.1

[Jan Kiszka]

On 11.08.25 11:45, 'Felix Moessbauer' via kas-devel wrote:
> In isar mode, a privileged executor is needed to remove the tmpdir(s).
> As of now, isar requires sudo, but we already prepare the code to be
> run0 compatible as well. By that, we can re-use the KAS_SUDO_CMD
> environment variable.
>
> Note, that the variable is not forwarded into the container, as the
> tooling inside the container is independent from the outside (e.g.
> outside you might want to use run0, while inside you have to use
> whatever is provided by the container).

...and what is provided by the container is not defined by kas?? Since when?

>
> Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
> ---
> docs/command-line/environment-variables.inc | 5 ++--
> kas/plugins/clean.py | 29 +++++++++++++++++++--
> 2 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/docs/command-line/environment-variables.inc b/docs/command-line/environment-variables.inc
> index b4ea240e8..ad1f04bf4 100644
> --- a/docs/command-line/environment-variables.inc
> +++ b/docs/command-line/environment-variables.inc
> @@ -201,11 +201,12 @@ overwritten using the ``env`` section of the config file.
> | | auto-detected (preference: docker). |
> +--------------------------+--------------------------------------------------+
> | ``KAS_SUDO_CMD`` | Explicitly set the sudo command (either ``sudo`` |
> -| (C) | or ``run0``) for operations that require higher |
> +| (C,K) | or ``run0``) for operations that require higher |
> | | privileges. If not set, this is auto-detected |
> | | (preference: ``sudo``). Note, that ``run0`` does |
> | | not preserve the environment and cannot setup |
> -| | loopback devices. |
> +| | loopback devices. The `KAS_SUDO_CMD` needs to be |
> +| | explicitly set inside the container. |

This is highly confusing. You need to elaborate about the differences
here and how one is supposed to use that inside the container then.

Jan