I am running some applications where application must know that it is running inside the PODMAN without any extra env variable but podman configuration inside the container must provide the detail without any user interactions.
As of now, I am using cat /proc/self/cgroup| grep -i 'machine.slice/libpod-*' inside the container started using podman to check if the process is inside the pod or not.
Is there a better way to handle the same?
From purely theoretical standpoint, using the approach with /proc/self/cgroup is a bad idea, as it is not guaranteed that the container engine would not spawn a container in a new cgroup namespace so that the containerized process would see its current cgroups simply as / like in the following example (unshare -C here emulates the container engine unsharing the cgroup namespace when starting the container):
$ podman run -it --privileged archlinux/base
[root@da0277b524db /]# unshare -C
-sh-5.0# cat /proc/self/cgroup
12:freezer:/
11:perf_event:/
10:pids:/
9:blkio:/
8:hugetlb:/
7:rdma:/
6:cpu,cpuacct:/
5:cpuset:/
4:net_cls,net_prio:/
3:memory:/
2:devices:/
1:name=systemd:/
0::/
From practical standpoint, container engines seem to care about compatibility with this trick, e.g. Moby uses the host cgroup namespace by default, and Podman seems to use the host cgroup namespace too, so this popular dirty check should succeed, but it is still an exploitation of an unintentional isolation breach, which exists since the times when the cgroup namespaces just did not exist.
What are alternatives?
When speaking about Podman specifically, it seems that the container engine inserts a special environment variable during the container spec creation to indicate that the containerized process is started using a specific container engine. So, even when you start your container without any additional variables, you may find the container variable in its place:
$ podman run -it alpine
/ # env | grep container
container=podman
While this approach is not bulletproof too (as nothing stops the container creator from overriding this variable), I feel that it is much better than the trick with /proc/self/cgroup, as this stuff is provided by the container engine intentionally, and it is unlikely to be overridden inadvertently, as this variable does not follow the general naming convention and does not use the ALL_CAPS style.