[2806637513] Upstream Reporter: Alexander Ivchenko
Upstream issue status: Closed
Upstream description:

Issue Description

When container is being removed, podman iterates through its exec sessions and checks whether exec session pid is still alive. The problem is that the pid can be reused for other processes, so that it may not belong to exec session. In this scenario podman may kill another process

I have seen a situation when podman-rm kills itself because pid was assigned to podman-rm itself :) The result is corrupted podman DB which doesn't allow to create container with same name, but also disallow to remove it because "container has already been removed". Probably, fresher versions of podman can handle this and container will be possible to remove, idk

But still, podman may kill processes it's not supposed to kill - this is the main issue

We have forked version of podman, but looking through the code of latest one it seems to me the issue still exits. Such problems caused by pid reuse are quite uncommon, but they happen in large clusters

The first idea I came up to fix this is to store process start timestamp as well as pid. Combination of (pid, start) is good enough to determine whether pid belongs to created exec session or not

P.s. We use forked (long time ago) version, but it seems to me, problem is relevant for latest podman as well

Thanks in advance

Steps to reproduce the issue

Steps to reproduce the issue

1. Create container
2. Exec into it
3. Kill exec session
4. Wait exec session pid to be reused by another process
5. Remove the container

Describe the results you received

if pid exists it will be killed by podman

Describe the results you expected

pid is not killed because it belongs to another process

podman info output

version: forked from 1.6.2

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

No

Additional environment details

Additional environment details

Additional information

No response