Edward Bartolo <edbarx@???> writes:
> I am not putting in doubt what you are telling me.

You are. And you are - pardon my frankness - very much confused
regarding how 'processes and process relationships' work on UNIX(*)/
Linux. I'll try to clear this up but you might want to consider getting
yourself a good book on the topic.

> In my implementation, the backend is run from within the code of the
> frontend, so its ppid is the pid of the frontend.

This is correct.

> Occurrences of execl, create another child process which is owned by
> the backend, but the latter, dies as soon as the child process is
> created.

This isn't: execl doesn't create a child process associated with the
process invoking it but it makes this process execute a new program. You
can see this for yourself. Save the following two C source code files to
some directory as a.c and b.c.

---- a.c -----
#include <stdio.h>
#include <unistd.h>

int main(void)
{
    printf("I'm program-1, my pid is %lu and my parent is %lu\n", getpid(), getppid());
    execl("./program-2", "p2", (void *)0);
    return 0;
}
--------------

---- b.c ----
#include <stdio.h>
#include <unistd.h>

int main(void)
{
    printf("I'm program-2, my pid is %lu and my parent is %lu\n", getpid(), getppid());
    return 0;
}
-------------

compile them into exectuables named program-1 and program-2 via

gcc -o program-1 a.c
gcc -o program-2 b.c

and run program-1. The output should be (with different actual pids, of
course)

[rw@doppelsaurus]/tmp#./program-1
I'm program-1, my pid is 8935 and my parent is 3395
I'm program-2, my pid is 8935 and my parent is 3395

> The orphaned child is related to the frontend, but its direct parent
> being dead, is assigned the pid of the frontend as its parent.

Orphaned child processes don't become children of the parent of their
original parent, they become children of init/
the-process-with-pid-1. init mostly just executes a wait-loop in order
to collect (and ignore) the exit status of any process assigned to it in
this way to prevent them from turning into zombies.

> The complications arise considering the fact, that the backend runs with root
> privileges,

[...]

> It seems, the fact that child processes created by instances of the
> backend, are thus owned by root, and the frontend is not permitted to
> wait() and reap them.

As the example program from my last mail should have demonstrated:
This is also wrong. A process can collect the status of one if its
children even if the child is executing under a different euid and if
this different euid happens to be 0.

BTW: Despite I don't have a WiFi-capable computer here, I cloned the
edbarx/netman.git repository to see if I could perhaps fix
this. However, the code available via

https://git.devuan.org/edbarx/netman.git

doesn't compile. The backend_src/bin and backend_src/obj directories are
missing. This is likely due to a misfeature (IMO) of all SCMs I've been
using so far, namely, they drop empty directories. You can avoid this by
creating a dummy file in both, eg,

touch backend_src/obj/.keep
touch backend_src/bin/.keep

and check them into git like this

git add backend_src/obj/.keep backend_src/bin/.keep
git commit -a -m 'directories needed by the build system'

After doing this, the build aborts with

backend.pas(96,13) Error: Identifier not found "RunCommand"

(occurs a couple of times). I could fix this but since this seems like a
minor oversight to me, I suggest that you put the missing stuff into the
public repository instead.