What is the TrustedInstaller Entity You See in Windows Vista?

A question came up in one of the comments asking me to please define TrustedInstaller. I’ve talked about it before a few times, but I’ve never gone through and dug through the implementation in a visible way. Time to change that – and we can do so with the help of some built-in command line tools, with a little power assist from Sysinternals.

Here’s the dialog you can have with these tools to illustrate how this works, so you can see it rather than just reading somebody tell you about it:

c:Windows>REM What does the ACE actually say?

c:Windows>icacls explorer.exe
explorer.exe NT SERVICETrustedInstaller:(F)

Successfully processed 1 files; Failed processing 0 files

c:Windows>REM OK, let’s get the SID for that…

c:Windows>psgetsid “NT SERVICETrustedInstaller”

PsGetSid v1.43 – Translates SIDs to names and vice versa
Copyright (C) 1999-2006 Mark Russinovich
Sysinternals – www.sysinternals.com

SID for NT SERVICETrustedInstaller:

c:Windows>REM This SID is one of the new Service SIDs in Windows Vista

c:Windows>REM How do we verify which one? sc.exe has a new option

c:Windows>sc showsid TrustedInstaller

NAME: TrustedInstaller
SERVICE SID: S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

c:Windows>REM yep – it’s the same one! How does this appear in the

c:Windows>REM services MMC console?

c:Windows>sc getdisplayname TrustedInstaller
[SC] GetServiceDisplayName SUCCESS
Name = Windows Modules Installer

c:Windows>REM And there you have it – here’s the principal you’re looking for

Comments (4)

  1. Greg Lambert says:

    These tips and tricks are really helpful. Understanding the Microsoft Component Based servicing stack and the Package Manager (ala Windows Installer) is essential to figuring out how applications install, uninstall, self-heal and repair under Vista and Windows Server 2008.

  2. ABC says:

    only these Trusted installers will have complete rights to do anything on these WRP files and registries, right?.

    some applications are having WRP related issues, but still those applications will work on vista. How it is possible?….why this WRP is not breaking the functionality of the application, even the application is having the issue.

    sometimes if it is breaking the functionality, we are applying the WRPRegisterDLL, WRPMitigation  kind of shims and it gets resolved. When we apply this shim, will it give permissions to modify those WRP files/registries?

  3. cjacks says:

    WRPMitigation is automatically applied to anything we detect as a setup, which is typically the time when most of these things occur. That’s why you don’t see it much. (Even misbehaving apps tend to try and drop old copies of things like shell32.dll at install time only.)

    No, we never give files permission to write there – we just create a new temp file and return this handle, so the app thinks it’s writing there. If shimming it made writing there possible, and we auto-shimmed it, it’d be a pretty bad protection mechanism…