Open calestyo opened 11 months ago
Well but as I wrote quite lengthy, this is actually a security hole as any process may thereby fake it's executable to be something else.
So could you please reopen and ... well simply not do this?
Sorry, I was in a rush and only focused on the first part of your post.
I see your point. Reopening, but I'll have to think about this. Maybe we can add a guess=True
argument.
No worries.
Uhm, I would rather suggest to call it unsafe
. That makes it much more of a heads up and people have a better chance to actually realise what's going on and make a proper choice.
And adding some warning box in the documentation, that when this is True
processes might hide their own true executable, would be nice.
Summary
Description
I wondered how
psutil
the following can happen.As a normal user:
the
exe
information (and others) for these processes (which areXorg
andlightdm
) cannot be read.But their
cmdline
can:Now, when again as the same user (UID
1000
), I do the following with psutil:So if
exe
is unreadable in both cases, how can it know theexe
in the first case?My assumption is, that it somehow takes
cmdline
, but perhaps only if that starts with an absolute path?I tried to look it up in the code, but couldn't find anything at a first glance: https://github.com/giampaolo/psutil/blob/master/psutil/_pslinux.py#L1763-L1773
If it would somehow use
cmdline
, that would IMO be a security hole. Processes can modify their owncmdline
so when another process would e.g. trust thatexe()
returns the right executable, this might be wrong and so the user ofexe()
could be lead into doing bad things.Any idea how your code does the magic to get the executable despite the symlink in
/proc
not being readable?Thanks, Chris.