Provide metadata to identify a container from inside

[debarshiray]

/kind feature

Description

Sometimes I come across people who are looking for ways to identify their Toolbox containers while sitting inside them. One use-case is to customize the shell prompt, just like one of those fancy Git prompts that identify the current branch and such.

I don't know what the ideal format would be.

Flatpak puts a INI-style file with stanzas at /.flatpak-info that describes the container. JSON is another option, but it isn't something that you can parse using the barebones POSIX shell utilities.

Output of podman version:

Version:            1.9.1
RemoteAPI Version:  1
Go Version:         go1.13.10
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  gitCommit: ""
  goVersion: go1.13.10
  podmanVersion: 1.9.1
host:
  arch: amd64
  buildahVersion: 1.14.8
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.15-1.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.15, commit: 4152e6044da92e0c5f246e5adf14c85f41443759'
  cpus: 4
  distribution:
    distribution: fedora
    version: "31"
  eventLogger: file
  hostname: kolache
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.4.14-200.notify.fc31.x86_64
  memFree: 1459437568
  memTotal: 8107806720
  ociRuntime:
    name: crun
    package: crun-0.13-2.fc31.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.13
      commit: e79e4de4ac16da0ce48777afb72c6241de870525
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-0.4.0-20.1.dev.gitbbd6f25.fc31.x86_64
    version: |-
      slirp4netns version 0.4.0-beta.3+dev
      commit: bbd6f25c70d5db2a1cd3bfb0416a8db99a75ed7e
  swapFree: 4133482496
  swapTotal: 4133482496
  uptime: 36m 30.59s
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  configFile: /home/rishi/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 0
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.0.0-1.fc31.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 1.0.0
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  graphRoot: /home/rishi/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 2
  runRoot: /run/user/1000/containers
  volumePath: /home/rishi/.local/share/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):

podman-1.9.1-1.fc31.x86_64

[mheon]

Easy enough to do. Only 2 real questions in my mind are:

• What metadata to include?
• What format to use?

[mheon]

Initial suggestions on the first one: Full ID and name of the container, image it was created from (if applicable). Maybe whether we are rootless?

[alexlarsson]

Here is how a typical /.flatpak-info looks:

[Application]
name=org.gnome.gedit
runtime=runtime/org.gnome.Platform/x86_64/3.36

[Instance]
instance-id=3514724854
instance-path=/home/alex/.var/app/org.gnome.gedit
app-path=/var/lib/flatpak/app/org.gnome.gedit/x86_64/stable/8a739f92d76e9cb67976d63b3c307089340b6197ef0183575f5e21c97549b3b8/files
app-commit=8a739f92d76e9cb67976d63b3c307089340b6197ef0183575f5e21c97549b3b8
runtime-path=/home/alex/.local/share/flatpak/runtime/org.gnome.Platform/x86_64/3.36/ad7f022f9489ce44301a53fb2707858e8d38a9632ee4ee634885f1b618d858cf/files
runtime-commit=ad7f022f9489ce44301a53fb2707858e8d38a9632ee4ee634885f1b618d858cf
runtime-extensions=org.gnome.Platform.Locale=632d8a1afcb20db2f533b00cf4c3780e3494cff681ae08a692ed7805258e1784;org.freedesktop.Platform.GL.default=0d51f4a9d159c86e56afd387531de155129b1d5439d530133fc4b972713165bf;org.freedesktop.Platform.GL.nvidia-440-82=0ee7950a8725c1a50ed4a88052533f2d37993a2521f3eab28e6495799886eb35;org.freedesktop.Platform.openh264=15266352ca7587793d013fdb17530a24d728e09be4f4cf315dc5bf99ad4323e8
branch=stable
arch=x86_64
flatpak-version=1.6.3
session-bus-proxy=true
system-bus-proxy=true

[Context]
shared=ipc;
sockets=x11;wayland;
filesystems=/foo;host;

[Session Bus Policy]
org.gtk.vfs.*=talk

[Environment]
GI_TYPELIB_PATH=/app/lib/girepository-1.0
GST_PLUGIN_SYSTEM_PATH=/app/lib/gstreamer-1.0:/usr/lib/extensions/gstreamer-1.0:/usr/lib/x86_64-linux-gnu/gstreamer-1.0
XDG_DATA_DIRS=/app/share:/usr/share:/usr/share/runtime/share:/run/host/user-share:/run/host/share

I think, somewhat in order of importance, what most people are interested in is:

• Am I in a container or on the host
• What sort of container technology is used (i.e. flatpak vs podman)
• What sort of environment am i running in (flatpak app+runtime, container name, base image name, etc)
• What kind of permissions do I have wrt the host (network access, fs access, uid mapping, etc)

Beyond this, most things are similar to on the host system and you if you want to look for a feature or option you can just use whatever probing code you would use on the host.

[rhatdan]

We currently create /run/.containerenv with no data in it.
Docker creates /.dockerenv

We could populate these files with content, but don't we really need a standard location for returning this content between podman, buildah, cri-o, flatpack (bubblewrap?)
I believe .containerenv is the correct name for this but I guess we could argue about location.
Name value pairs is the best thing for bash to use.

[mheon]

The Flatpack example seems to be TOML, which seems like it would work pretty well as well

[mheon]

Ah, nevermind, it's not - no quoting, etc... I need more coffee

[mheon]

@ParkerVR PTAL

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@ParkerVR Any progress?

[vrothberg]

I suggest to create a package in common github.com/containers/pkg/containerenv and define a struct there along with a useful API to create and populate the file.

@lsm5 could you do this (after bug week)? The reasoning to pack it into c/common is to allow other tools to use it and semi-standardize on a format.

Once we a PR draft is open, we can start bikeshedding on the format and fields.

[rhatdan]

If someone wants to open a PR in containers/common to kick this off, it would be great. I like name value pares since it makes it easier to process from bash.

I would worry about information leakage, so we need to be careful about what goes into this file.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

Ok no one has stepped forward for the past month on this. But what kind of data do we want. Looking at @alexlarsson Data, I am not sure how much of this makes sense. Are you looking for more info then the following. There is a slippery line where we don't want to leak too much information into the container for hacker purposes.

[Container]
Names=TestContainer
Id=5f7540486e88b23c42ceb658c7576d1b73e07de3b0c67e016bd0c34d7e00095a
[Image]
name=registry.centos.org/centos:latest
digest=c46009597289604ac5b188492347119c00f274a5591bd8d2f08e50b3101fab1a
[Engine]
name=podman-2.2.0-dev

[juanje]

@rhatdan I think that, for most cases, you want/need to know which image (name, tag and digest) you are in. So, the info you propose should be more than enough.

I mean this for general purposes and cases like toolbox users. Some other use cases, as Flatpak, probably would need more info, but they already have their ways and it might be too much info for more general cases.

[debarshiray]

Yes, the container name and ID, and the image name and ID are the most important, I think.

As for the engine, would it be the version of Podman that started the container? Or the one that called podman create? I wouldn't mind leaving it out, unless someone specifically asks for it.

[rhatdan]

@debarshiray What do you think if we only give this information out in --privileged mode? Or have a config flag and containers.conf to say whether we reveal it.

Some engineers are raising concerns about the information leak, being a vector to attach the system.

[debarshiray]

Toolbox already uses --privileged, so that's fine. Any other flag that we can specify as a command-line argument is also fine.