search

end18 / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

Process uid and gid properties don't change once accessed #112

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
>>> import psutil, os
>>> proc = psutil.Process(os.getpid())
>>> os.getuid()
0
>>> proc.uid
0
>>> os.setuid(1000)
>>> os.getuid()
1000
>>> proc.uid
0
>>> 

What is the expected output? 
Expected output is 1000 since I changed process uid after process creation.

What do you see instead?
I keep seeing 0, which refers to status prior to os.setuid(1000) call.

Please use labels and text to provide additional information.
This is due to Process.uid and Process.gid properties being cached once 
accessed.
Caching should be removed and also they should be calculated in their own 
specific function rather than in get_process_info().

Original issue reported on code.google.com by g.rodola on 22 Sep 2010 at 11:03

GoogleCodeExporter commented 9 years ago 
Nice catch... what about username? Can ownership of a process be changed on 
UNIX, or only at startup of the process? If the former then it'll be affected 
by the caching as well.

Original comment by jlo...@gmail.com on 23 Sep 2010 at 12:54

GoogleCodeExporter commented 9 years ago 
Ownership of a process can be changed at any time during the profess life. 
Being username dependent from uid property it is affected as well.

Original comment by g.rodola on 23 Sep 2010 at 8:11

GoogleCodeExporter commented 9 years ago 
Mmm... Should I wait the integration of the big Windows patch (username, 
uptime, etc...) before doing this?

Original comment by g.rodola on 24 Sep 2010 at 9:57

GoogleCodeExporter commented 9 years ago 
I'm currently looking at this issue and it seems that in order to fix it we 
need to move a lot of stuff from get_process_info() which currently returns a 
(pid, ppid, name, exe, cmdline, uid, gid) tuple which is way too much 
information for a single function to return. 
IMO get_proess_info() should return (name, exe, cmdline) instead, and it would 
probably be better to rename it by using a more appropriate name 
(get_proess_static_info() maybe).

As said, this change involves a lot of code, so it's likely I'll break the code 
in the process.

Original comment by g.rodola on 9 Oct 2010 at 3:26

GoogleCodeExporter commented 9 years ago 
I recommend postponing this for a bit... this is a pretty minor issue (how 
often does UID/GID really change during a typical process lifetime), and it'd 
require changes to the core of the library.  The original reason for putting so 
much code in one C function was to consolidate data fetching in the C code. For 
example: start time, ppid, uid, gid, and command name and so forth are 
available from one sysctl() call on BSD/OSX. This is also why the proxy/deproxy 
code in __init__.py so we could do a lazy initialization of the data for the 
process. 

I think we can stand to do some  reorganizing of the code but let's take some 
time to figure out how to take advantage of it best for all platforms. We also 
have that large merge we're looking at for Windows platforms, so maybe it's a 
good time to rearrange things more efficiently and if we need to break some 
code we can do it all at once :-)

Original comment by jlo...@gmail.com on 9 Oct 2010 at 4:47

GoogleCodeExporter commented 9 years ago

Original comment by jlo...@gmail.com on 27 Oct 2010 at 3:44

GoogleCodeExporter commented 9 years ago 
In issue 111 we discovered that name, cmdline and exe properties strictly 
depend on each other, hence it seems it makes sense to retrieve them by using a 
single C call returning a (name, exe cmdline) tuple and reorganize the code as 
such on all platforms.

I understand the original rationale behind fetching also ppid, uid and gid in 
the same function since on BSD and OSX we retrieve them by using a unique 
sysctl() call but this does not apply for Windows and Linux where we uses 
different primitive calls to fetch them.

wj32.64 patch has been partially committed and the other parts no longer apply 
cleanly against the trunk anyway so if you agree I'd be for starting to 
reorganize the code unless you have other ideas.

Original comment by g.rodola on 27 Oct 2010 at 10:59

GoogleCodeExporter commented 9 years ago 
This has been fixed in various commits which have been tracked in issue 126.

Original comment by g.rodola on 3 Nov 2010 at 6:14

GoogleCodeExporter commented 9 years ago 
Issue 130 has been merged into this issue.

Original comment by g.rodola on 3 Nov 2010 at 10:14

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 13 Nov 2010 at 3:14

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 9 Jun 2011 at 10:33