Sending bug report here, as BTS registration is disabled. My report concerns libgpgme. Take a look around here: https://github.com/gpg/gpgme/blob/1ff1aa188240fb10fb13ab51c38836f973e08857/src/posix-io.c#L573
I don't think the code is really doing what the comment suggests. In Unix/Linux, a zombie (or defunct) process is one that has terminated but whose parent has not done a wait() or waitpid() on it. If the zombie's parent has also terminated, the zombie is given to PID 1 as its child. Normally, PID 1 is init or systemd and they have code to wait on any zombies they get. However, inside a Docker container, the entrypoint process ends up being PID 1. This could be any arbitrary process and likely does not have special code to wait on processes it did not spawn. I have seen this in my Docker containers, where many defunct gpg, gpgsm, and gpgconf processes were accumulating. A cursory read of that _gpgme_io_spawn() function shows that it does two fork() calls, but only one wait, via _gpgme_io_waitpid(). The grand-child does the actual execv of the desired command. The child exits right away. It's this child that is waited for. Basically, this code is designed to ship the zombie problem over to init/systemd to solve. Far from preventing zombies, it's creating parent-less zombies deliberately. This makes a big assumption about the execution environment. It could be a vulnerability if the process table fills up. What the library should do is to wait on every process that it forks. I'm not sure if the double-fork is needed, as I don't know if _gpgme_io_spawn() is meant to invoke long-running processes (like daemons) or not. If it's not, I'd think to do a single fork and make sure to wait. Otherwise, I'd think about a SIGCHLD handler to call wait, although doing this in a library may be an issue. If threads are available, having a list of PIDs to wait on periodically might work. In any case, the library should not be leaking resources out. I know this code is 20+ years old and probably considered stable. That said, it does not look correct to me and I think it can be the source of problems. Please take a look and consider the Docker environment. Thank you. --Alex _______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
