username test fails on Windows 2003, unable to map account name and security IDs

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Running test suite on my development system (Windows 2003 SP2)

Test suite errors: 

======================================================================
ERROR: test_test (__main__.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test\test_psutil.py", line 324, in test_test
      psutil.test()
  File "C:\Python25\Lib\site-packages\psutil\__init__.py", line 455, in test
    line = get_process_info(pid)
  File "C:\Python25\Lib\site-packages\psutil\__init__.py", line 425, in
get_process_info
    user = proc.username
  File "C:\Python25\Lib\site-packages\psutil\__init__.py", line 236, in
username
    self._procinfo.username =  _platform_impl.get_process_username(self.pid)
  File "C:\Python25\Lib\site-packages\psutil\_psmswindows.py", line 98, in
get_process_username
    return _psutil_mswindows.get_proc_username(pid)
WindowsError: [Error 1332] No mapping between account names and security
IDs was done

======================================================================
FAIL: test_username (__main__.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test\test_psutil.py", line 271, in test_username
    self.assertEqual(domain, expected_domain)
AssertionError: 'NT AUTHORITY' != 'JAY-GVIGVB4XUYD'

----------------------------------------------------------------------
Ran 39 tests in 0.875s

FAILED (failures=1, errors=1)

Original issue reported on code.google.com by jlo...@gmail.com on 4 Sep 2009 at 4:40

• Blocking: #70

[GoogleCodeExporter]

Additional note: username for the current Python process is returning "NT
AUTHORITY\\SYSTEM" for me when it should be the Administrator account. Not sure 
why
that is occurring, but that may help with investigating the issue.

Original comment by jlo...@gmail.com on 4 Sep 2009 at 4:53

• Changed state: Accepted

[GoogleCodeExporter]

Narrowed this down a little more, SidToUser() is the problem... the section 
following
this comment: 

  // LocalSystem processes are incorrectly reported as owned by BUILTIN\Administrators
  // We modify that behavior to conform to standard taskmanager

Is being executed every time since I am running as the Administrator account. 
It's
changing every process I execute to NT AUTHORITY\SYSTEM which is not correct in 
this
case. It should be showing SYSTEM only for those processes that are actually 
run by
the LocalSystem account, and ones started by the Administrator user should be 
showing
as Administrator.

I'm not sure exactly what the limitations are of the underlying API or why this 
code
was put in originally so I won't change anything until we've either discussed 
or I've
at least had a chance to do more testing.

Original comment by jlo...@gmail.com on 4 Sep 2009 at 5:01

[GoogleCodeExporter]

http://www.ddj.com/windows/184405986

"..there’s a way to determine whether we’re running under the Local System 
account.
However (you guessed it), we have to call more Win32 functions to determine 
this.
Backing up through the code listing, we need to make another call to
GetTokenInformation, but instead of passing through the TOKEN_USER constant, we 
pass
through the TOKEN_PRIVILEGES constant. This value returns an array of 
privileges that
the account has in the environment. Iterating through the array, we call the 
function
LookupPrivilegeName looking for the string “SeTcbPrivilege.” If the 
function returns
this string, then this account has Local System privileges."

Original comment by jlo...@gmail.com on 4 Sep 2009 at 5:20

[GoogleCodeExporter]

Yan do you have some time to take a look at this issue?

Original comment by billiej...@gmail.com on 17 Sep 2009 at 9:52

• Added labels: Milestone-0.1.3

[GoogleCodeExporter]

Ok, I've committed some changes as r435 so that we can now check if a process is
really a System-owned process. Now we only change BUILTIN\Administrator to NT
AUTHORITY\LocalSystem if it's really a system process. 

However, the two test suite errors are still there. I did some research and it 
looks
like the domain reported by the %USERDOMAIN% environment variable is by default 
the
computer name, and may not match what is returned by LookupAccountSid(). The 
MSDN
docs explicitly state that some standard system accounts (such as 
Administrator) will
return BUILTIN for the domain instead of the *actual* domain. For a non-builtin
account, the value should be the computer name if it's a standalone machine, or 
the 
domain name if the user is logged into a domain. 

In those cases we can test against USERDOMAIN, but I don't think we can rely on 
it as
a test case because it won't work correctly for anyone running as Administrator 
or
any other builtin accounts. We'll need to find some other way of testing the 
username
property instead of comparing it to the USERDOMAIN env variable. Maybe ignore 
the
domain and just check the USERNAME env variable against what we get for the 
username
portion.

Original comment by jlo...@gmail.com on 19 Sep 2009 at 9:39

• Removed labels: Milestone-0.1.3

[GoogleCodeExporter]

One more note before I go to bed - the ERROR_NONE_MAPPED problem appears to be 
always
being caused by svchost on my machine, owned by NETWORK SERVICE. 
LookupAccountSid
fails for this process each time it's run and causes the exception to be thrown.
Looks like more research is in order to figure out why this is happening and 
what we
can do as a workaround.

Original comment by jlo...@gmail.com on 19 Sep 2009 at 10:08

[GoogleCodeExporter]

Original comment by billiej...@gmail.com on 19 Sep 2009 at 6:04

• Added labels: Milestone-0.1.3

[GoogleCodeExporter]

Ok, I figured out what's going on with this error: 

WindowsError: [Error 1332] No mapping between account names and security
IDs was done

Unfortunately, I don't know how to fix it yet :-P 

This is coming from process svchost.exe on my system, owned by NETWORK SERVICE 
user.
I wrote some debugging code to print out the SIDs in string form, and I 
determined
that the code in get_proc_username() is retrieving the *logon* SID instead of 
the
actual process owner's SID. I believe this is happening because this particular
svchost.exe is launched as a logon process, but I'm not 100% sure on that part. 
In
any case, because the logon SID is being checked instead of the process owner 
SID,
LookupAccountSid() is not able to map it to a logon name and it errors out.

I tried playing around with OpenProcessToken() and GetTokenInformation() 
instead of
using GetKernelObjectSecurity() and GetSecurityDescriptorOwner(), but this 
fails with
an access denied error for processes not owned by me. I did note something
interesting during testing; when using this method: 

OpenProcessToken()
GetTokenInformation()
LookupAccountSid()

I actually got this returned for the domain/user: 
JAY-GVIGVB4XUYD\Administrator

Whereas with the existing code (which uses LookupAccountSid() as well) I get 
this:  
BUILTIN\Administrators

I am guessing the SID we get from each method is not the same, and it looks 
like the
method using OpenProcessToken() is more accurate, but only useful if we can work
around the access denied errors. I am looking into this some more, it *may* be
possible to set privileges to make ourselves the owner of the process 
temporarily or
something similar so that we can have rights to read the information (see
http://www.mombu.com/microsoft/scripting-vb-script/t-hprocessgetowner-is-slow-al
ternative-needed-3110692.html
for some ideas). Maybe if yan has a chance to take a look at this he'll be more
successful in making progress on this - if we can find a way to make the
OpenProcessToken() method work for all processes it'll actually fix both of 
these
errors at the same time.

Original comment by jlo...@gmail.com on 19 Sep 2009 at 11:47

[GoogleCodeExporter]

As it seems there are no progresses about this issue I think the best we can do 
for
now is raising AccessDenied as a measure of last resort.
I committed the change as r435.
I'd like to leave this open to remind us that we used this workaround.

Original comment by billiej...@gmail.com on 30 Jan 2010 at 6:52

• Changed state: Started

[GoogleCodeExporter]

This issue should be related with Issue #71:
http://code.google.com/p/psutil/issues/detail?id=71#c8

Original comment by billiej...@gmail.com on 4 Feb 2010 at 8:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This should hopefully and finally be fixed in r479 in which wmi.py module 
(requiring
pywin32 extension) is adopted to retrieve the process username.
In case pywin32 is not installed a NotImplementedError exception is raised.

I placed wmi.py in psutil source code tree and it gets installed as a separate 
module
by setup.py by temporarily copying it in the same directory as setup.py. 
This sucks but I really didn't find another way around.

I'm going to make sure that everything works as expected on both Windows XP and
Windows 7 before closing this out.

Original comment by billiej...@gmail.com on 10 Feb 2010 at 10:44

[GoogleCodeExporter]

Verified that everything works as expected on both Windows XP and Windows 7 64 
bit.
Closing this out as fixed.

Original comment by billiej...@gmail.com on 11 Feb 2010 at 10:25

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Updated csets after the SVN -> Mercurial migration:
r435 == revision c96abce3ffa3
r479 == revision 5fda567f54ea

Original comment by g.rodola on 2 Mar 2013 at 11:50