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

[giampaolo]

From [email protected] on September 04, 2009 06:40:49

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

[giampaolo]

From [email protected] on September 03, 2009 21:53:32

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.

Status: Accepted

[giampaolo]

From [email protected] on September 03, 2009 22:01:00

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.

[giampaolo]

From [email protected] on September 03, 2009 22:20:28

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."

[giampaolo]

From [email protected] on September 17, 2009 14:52:04

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

Owner: yanraber
Labels: Milestone-0.1.3

[giampaolo]

From [email protected] on September 19, 2009 02:39:35

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.

Owner: jloden
Labels: -Milestone-0.1.3

[giampaolo]

From [email protected] on September 19, 2009 03:08:31

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.

[giampaolo]

From [email protected] on September 19, 2009 11:04:01

Labels: Milestone-0.1.3

[giampaolo]

From [email protected] on September 19, 2009 16:47:58

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-alternative-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.

[giampaolo]

From [email protected] on January 30, 2010 10:52:40

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.

Status: Started

[giampaolo]

From [email protected] on February 04, 2010 12:35:06

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

[giampaolo]

From [email protected] on February 10, 2010 14:44:18

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.

[giampaolo]

From [email protected] on February 11, 2010 14:25:45

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

Status: Fixed

[giampaolo]

From g.rodola on March 02, 2013 03:50:33

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