Closed debarshiray closed 3 years ago
Easy enough to do. Only 2 real questions in my mind are:
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?
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:
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.
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.
The Flatpack example seems to be TOML, which seems like it would work pretty well as well
Ah, nevermind, it's not - no quoting, etc... I need more coffee
@ParkerVR PTAL
A friendly reminder that this issue had no activity for 30 days.
@ParkerVR Any progress?
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.
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.
A friendly reminder that this issue had no activity for 30 days.
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
@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.
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.
@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.
Toolbox already uses --privileged
, so that's fine. Any other flag that we can specify as a command-line argument is also fine.
/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
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):