Consider adding a marker file like /.flatpak-info

[matthiasclasen]

This was suggested to my by Christian Hergert.

It would help him to improve debugging and tracing apps running in toolboxes.

Something like /.toolbox-info would be a nice parallel to what flatpak does. Alternatively, the already existing /run/.containerenv could maybe add enough information to clearly identify a container as a toolbox. E.g., it could show the container-init process.

[matthiasclasen]

When we tried to look for /run/.containerenv in Nieves' toolboxes, we could not find it, so there may be some unreliability in what podman does. The documentation sounds like the file may depend on the --privileged flag. That might be another reason for having our own marker file that is always there.

[debarshiray]

Something like /.toolbox-info would be a nice parallel to what flatpak does.

We do already have an empty /run/.toolboxenv to identify Toolbx containers that sits next to the more generic /run/.containerenv added by Podman.

If it's only a matter of filtering Toolbxes from other Podman containers, then /run/.toolboxenv should work. eg., it's already used in /etc/profile.d/toolbox.sh.

Alternatively,
the already existing /run/.containerenv could maybe add enough information to clearly
identify a container as a toolbox. E.g., it could show the container-init process.

Currently, /run/.containerenv inside a Toolbx container looks like:

engine="podman-4.2.0"
name="fedora-toolbox-36"
id="f030bfbfa089c191ab617f12d66a407e712b0e2b0c5a2f8dc5bced1dc0fbd1e2"
image="registry.fedoraproject.org/fedora-toolbox:36"
imageid="a68a838b182ac44d4d53330bbe3aa49f9a7239f420bea22a8650f765ac4c1a9c"
rootless=1
graphRootMounted=1

Do we only need a way to identify a Toolbx? Or do we need some more information? We could request Podman to add some more metadata bits to that file.

[debarshiray]

When we tried to look for /run/.containerenv in Nieves' toolboxes,
we could not find it

That's odd.

What about the Annotations and CreateCommand fields in the podman inspect --type container <CONTAINER> JSON? Do they contain privileged?

I have:

$ podman inspect --type container fedora-toolbox-36 | grep privileged
                    "io.podman.annotations.privileged": "TRUE",
                    "--privileged",

The documentation sounds like the file may depend
on the --privileged flag.

A /run/.containerenv file should always be there, regardless of whether the container was created with --privileged or not. The --privileged flag decides whether the file would be empty or have some metadata in it. That's because people were worried about potential security problems caused by the information leaking out through the /run/.containerenv file.

Toolbx containers are always created with --privileged, so they should always have a non-empty /run/.containerenv.

[debarshiray]

By the way, the /run/.toolboxenv file is mentioned in the podman-create(1) manual under Container Configuration.

There's also the com.github.containers.toolbox label for identifying Toolbxes from the host, which is used by toolbox list.

[matthiasclasen]

Thanks, I'll ask Christian Hergert to chime in here with what, if anything, would be useful for him.

[chergert]

I think toolbox is the easier of situations to solve, at least when it comes to sysprof symbol decoding. If we know we can rely on access to the host file-system, symbol resolving can mostly be a "add this prefix to symbol paths to find the real .so/binary on the host".

[matthiasclasen]

@chergert Is other information about the toolbox setup that would be useful to you, that could be included in /run/.toolboxenv ?

[chergert]

Perhaps the location where the host system is mounted, so that we don't hard code things? But honestly, I'm fine with hard coding.

I think I'll know more once we have a prototype to fix symbol resolving though.

[debarshiray]

Perhaps the location where the host system is mounted, so that we don't hard
code things? But honestly, I'm fine with hard coding.

At the moment, it should be fine to hard code /run/host as the location where the host filesystem is bind mounted inside the container.

Flatpak has a similar location, but I have heard that /host is used in the world of OpenShift.

Regardless, /run/host is crucial for Toolbx at the moment. It's even embedded inside the toolbox binary.

[chergert]

Thanks!

I think it's probably fine to close this issue now until we have concrete needs for Sysprof/Builder/etc.

[matthiasclasen]

ok, closing this. Thanks for the discussion