Thoughts on adding an option to execute ps with sudo

[zlesnr]

Is your feature request related to a problem? Please describe.
On some linux machines, I'm seeing lately, that /proc is mounted with hidepid=2, which hides process for which the current user does not have access. This means that when process.PidsWithContext() is called, the user may not have a complete picture of a host environment, as to be expected from the mount option. But perhaps I don't want to change this option, and I also don't want to run entire binary as root in order to get a full process list.

Describe the solution you'd like
Execute ps with sudo.

Describe alternatives you've considered
Running the binary as root.

Additional context
What are the thoughts about the right way to approach this? I see that the code builds a set of arguments to ps for the proper invocation and then parse the results. Sudo is pretty common, but I know runas and doas exist somewhere that would have mostly the same effect. I wouldn't know where to start on some of the other supported platforms in this project.

[Lomanic]

ps is not called on linux in process.PidsWithContext(), gopsutil lists PIDs by reading into /proc (it is way more costly to fork() to an external process like ps than doing what it does in Go itself).

Even if it was called, sudo (or an alternative) could lock the calling process (or it would simply fail, so same result as before) if the current user is not setup with passwordless sudo rights in sudoers. And handling this case (a way to provide the sudo password) is quite a task (pulling an expect library. just for this for example), which could even be multiplied for doas and runas.

If you want a process to be able to list running PIDs with gopsutil, you have to add its running user to a specific group and mount /proc with this group as gid option (as specified also in the Mount options section of procfs documentation), which is the most sensible option instead to me.

[zlesnr]

Thank you for the response. I think I was reading the darwin code last week when I was seeing the ps execution. I hear you about being more cost effective to execute the proc tree in place of forking. Thanks for the pointers about the gid option on /proc mounts.