-
-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DRAFT: run: add --host-share-pids to reuse host pid namespace #5441
base: main
Are you sure you want to change the base?
Conversation
This allows exposing a process to the PID namespace of the host. That can be useful when you need to expose tooling that will process various /proc information such as profilers and systems tooling. Typically this is not enabled because once you do, processes can use ptrace on each other and generally circumvent the sandbox.
For this to be actually useful, wouldn't it need to be a static permission that apps opt in to? Flathub would then, of course, need to block it by default too, with exceptions for those apps that need it. |
Not at all. Builder could use it when running applications under the profiler so that data can be correlated while recording. That doesn’t need a public permission at all. |
And what for system monitors, like Mission Center? That's one use case where this would be very nice to have. Right now it's constantly spawning a static binary on the host, and it's not fun. It would simplify everything if this was a normal permission apps could just opt into. |
Out of scope. Not every use case has to be covered by a single feature.
It seems to work, so what's the issue? |
It just seems like common sense to roll in a permission here, at least to me. This is partially working as-is, and I'd like it to be fully working from the start.
One could view this as an app or proxy problem, not a hack problem, but it appears to be a contributor to a memory leak somewhere, and the information it gets is wrong. But I need to check and make sure that problem still exists. |
Sysprof is in a similar situation, but more extreme. Because not only does it need access to That isn't needed for the I'll probably be doing some work to address this over the GNOME 46 cycle though and I'd expect it to be solved in a very different manner than this. |
This allows exposing a process to the PID namespace of the host. That can be useful when you need to expose tooling that will process various /proc information such as profilers and systems tooling.
Typically this is not enabled because once you do, processes can use ptrace on each other and generally circumvent the sandbox.
This is mostly a draft as it really depends on what we'd like to do with #3922
If we decide to go ahead, I can take care of adding documentation, etc.