[Part 2 of 2] Last time, we began looking at the steps to determine the account that a Windows Service ran under programmatically. In this issue, we’ll finish up the set of steps and I’ll give some final thoughts on the Local System account.
We left off looking at some code that retrieved the TOKEN_USER structure for the current process. However, that step didn’t get us down to the actual user account that we need. To do that, we have to call another Win32 function, named LookupAccountSid:
char szUserName[1024], szDomainName[1024]; ZeroMemory(szUserName,sizeof(szUserName)); ZeroMemory(szDomainName,sizeof(szDomainName)); DWORD dwUserSize = sizeof(szUserName)-1; DWORD dwDomainSize = sizeof(szDomainName)-1; SID_NAME_USE sidType; ::LookupAccountSid( NULL, pUserToken->User.Sid, szUserName, &dwUserSize, szDomainName, &dwDomainSize, &sidType))
Looking at this code, we see another example of the hideous way Windows deals with returning strings—I dimension a buffer and zero it out, pass a pointer to it to the function and the size, all the while hoping that my buffer isn't too small. This isn't as bad as some SDK functions where I would make an initial call to request the size of the buffer and then call the function with that buffer size, but it's close. This is probably one of the classic areas where C/C++ programmers get bit by the off-by-one bug because they fail to pass in a size less than they've dimensioned—in order to account for a trailing NULL. Not doing this means you might get back a fully populated buffer with no room for the NULL and Zoom! Off you go through blocks of memory ending up who knows where.
The call to LookupAccountSid is the final magic step to get the user account information we’ve wanted all along. We get back both the username and domain (assuming the user is a member of a domain). Finally, we delete the memory we allocated and close the handles we received:
delete [] static_cast<char*>(pUserToken); ::CloseHandle(tokenHandle); ::CloseHandle(processHandle);
That's a lot of steps to go through to get an account name on a process. It would have been handy if Microsoft would have provided a GetCurrentProcessAccount function similar to GetCurrentProcessId to retrieve this information. But they didn't, so we are left with the series of steps to get there.
OK, so we’re all done, right?
Well, no, we’re not. A careful reader of the code may have picked up that it doesn’t deal with the condition of a process running under the Local System account—this account is a system account that has no credentials (i.e., it does not require a username or password) and thus has no access rights to network resources. Many Windows Services use this account in order to utilize a known account with restricted rights; for example, the services that come with the operating system typically run under the Local System account. However, the code I listed above won’t deal with this situation at all.
But take heart, because 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.
Yikes.
Like I said at the beginning of this article, this is one of those functions you wrap up and put in your toolbox of tricks. Maybe call it something like IsLocalSystemAccount. But you certainly don’t want to have to remember all of these steps the next time you need to determine the account of a running process.
Mark M. Baker is the Chief of Research & Development at BNA Software located
in Washington, D.C.
Do you have a Windows development question? Send it to [email protected].
