1. Should the library call it? imho this should be something done by the user, not by the library. So we should only update examples, and documentation, so user knows how to use this API. Imho this is security variability, if we do it always, without user consent.

2. Do it even work? We set permission to parent process. Our tests will work as producer and customer shares the same parent process. What if producer, and consumer are different parents? I.E are start from different bash processes.

1. Should the library call it? imho this should be something done by the user, not by the library. So we should only update examples, and documentation, so user knows how to use this API. Imho this is security variability, if we do it always, without user consent.

It's for the ease-of-use of the UMF IPC API. Perhaps at least we should enable tracing with a new CMake option so the user enables tracing explicitly? And this would be disabled by default as UMF users not using IPC API would not be interested in setting ptrace scope wider.

2. Do it even work? We set permission to parent process. Our tests will work as producer and customer shares the same parent process. What if producer, and consumer are different parents? I.E are start from different bash processes.

It works for MPI ranks communication. That's the case covered in our tests where producer and consumer share the same parent process. As for the different parents case, it's not tested but I think it could work if they are using the same shared umf library.

As for the different parents case, it's not tested but I think it could work if they are using the same shared umf library.

This is about kernel level process security protection/permissions - common shared library between processes do not have to influence here.