Process uid and gid properties don't change once accessed

[giampaolo]

From g.rodola on September 23, 2010 01:03:31

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: http://code.google.com/p/psutil/issues/detail?id=112

[giampaolo]

From [email protected] on September 22, 2010 17:54:43

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.

[giampaolo]

From g.rodola on September 23, 2010 13:11:15

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.

[giampaolo]

From g.rodola on September 24, 2010 14:57:10

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

[giampaolo]

From g.rodola on October 09, 2010 08:26:07

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.

[giampaolo]

From [email protected] on October 09, 2010 09:47:54

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 :-)

[giampaolo]

From [email protected] on October 26, 2010 20:44:20

Labels: OpSys-All

[giampaolo]

From g.rodola on October 27, 2010 15:59:04

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.

[giampaolo]

From g.rodola on November 03, 2010 11:14:58

This has been fixed in various commits which have been tracked in issue 126 .

Status: FixedInSVN
Labels: -Progress-0in4

[giampaolo]

From g.rodola on November 03, 2010 15:14:53

Issue 130 has been merged into this issue.

[giampaolo]

From g.rodola on November 12, 2010 19:14:59

Status: Fixed

[giampaolo]

From g.rodola on June 09, 2011 15:33:51

Labels: -OpSys-All