Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
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
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
Original comment by billiej...@gmail.com
on 19 Sep 2009 at 6:04
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
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
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
[deleted comment]
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
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
[deleted comment]
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
Original issue reported on code.google.com by
jlo...@gmail.com
on 4 Sep 2009 at 4:40