I have encountered a privilege difference in Windows Installer between XP and Vista RC1 which makes our installation fail. I have searched for an explanation and workaround but haven't found anything so far. This is NOT a UAC issue: the difference in privileges is there even when UAC is off.
The Problem:
In Vista RC1, a custom action of type 3074 runs WITHOUT having the SeBackupPrivilege privilege. The privilege is not there so it is not possible to enable it using AdjustTokenPrivileges. (Type 3074 custom action is an EXE that runs from a temp file using deferred execution in the Local System context.)
In XP SP2 and earlier versions of Windows, this custom action has the SeBackupPrivilege privilege so it is possible to enable it using AdjustTokenPrivileges.
Our custom action needs to enable SeBackupPrivilege and SeRestorePrivilege in order to use RegLoadKey.
Questions:
1. Is this an intentional difference between XP (msiexec.exe 3.1.4000.1823) and Vista RC1 (msiexec.exe 4.0.5600.16384)?
2. How can I run an EXE as a custom action so that it can enable SeBackupPrivilege and SeRestorePrivilege and then call RegLoadKey?
3. If there is no way to do the above (question 2), is it possible to run some kind of custom action that could enable SeBackupPrivilege and SeRestorePrivilege and then call RegLoadKey?
I am afraid currently we don't offically support the Vista platform issue in this newsgroup. I suggest you consult thsi problem in our corresponding MSDN forum, you'd get better and quicker help there:
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
According to the document, a service can be defined to run as LocalSystem and yet also specifiy a reduced subset of privs. If you look at the way MsiServer is defined as a service it requests the following rights. You'll notice that the two rights the posted asked about are not isted.
Up until this point the impersonate issue and UAC has been discussed about writing deferred CA's, but I have not seen this issue raised as a possible reason for CA's to fail.
My guess is if you add the privilege to the service definitino and restart MsiServer your CA will start working. It also seems that Microsoft should either document why this priv was taked away or fix it in Vista.
Thank you, Christopher!!! Your findings definitely explain why the problem occurs. I didn't yet get an answer from MS support in the Vista forum either but I posted a link to your blog article there as well to save them some time :-)
Christopher wrote: > I'm suspecting that this is a defect in the MSI 4.0 in Vista > Microsoft should either document why this priv was taked away or fix it in > Vista
My opinion on the issue is exactly the same. How can I take this issue further? What is the proper way of reporting this as a defect in MSI 4.0 in Vista and request Microsoft to fix it? I'm sure there are others out there who are calling RegLoadKey in a deferred custom action in their installer (e.g. in order to manipulate other users' HKCU registry settings). RegLoadKey requires SeBackupPrivilege. I believe this issue should be fixed, otherwise some installers will be failing in Vista.
If this issue is not fixed, is there any way to use RegLoadKey in a deferred custom action in MSI 4.0 in Vista?
As I understand it, once the SCM starts the msiserver process there is no way to get the right added. The only hack I can think of would be a bootstrapper that is manifested to ask for Admin rights and then grant the missing right to the service and restart the service. This way when your defferred CA executes the priv will be in the token.
"Antti Nivala" <niv...@newsgroup.nospam> spake the secret code <uJ6RiCJ7GHA.3...@TK2MSFTNGP05.phx.gbl> thusly:
>Our custom action needs to enable SeBackupPrivilege and SeRestorePrivilege >in order to use RegLoadKey.
Since RegLoadKey just dumps a bunch of stuff into the registry from a file, is there some reason you're not using the Windows Installer tables to perform these registry modifications?
>>Our custom action needs to enable SeBackupPrivilege and SeRestorePrivilege >>in order to use RegLoadKey.
> Since RegLoadKey just dumps a bunch of stuff into the registry from a > file, is there some reason you're not using the Windows Installer > tables to perform these registry modifications?
Not sure exactly why Antti Nivala needs this capability but I would bet the most common use of this would be to attempt to enumerate all local profiles and load each user's registry hive in order to remove/add HKCU values. You simply can't do this sort of "one shot all users affected" install by using the standard Registry table.
The "typical" MSI way would be to use components with HKCU KeyPaths and having each user trigger the install to ensure the HKCU values are created. But this method is not so good for uninstalling those same values and the other way does it better (well somewhat better... ok debatably better ;)
Ultimately Vista is a new beast and everyone has to play by the new rules. Microsoft is clearly stating to all that while backwards compatibility is high on the list, security is paramount for Vista. Just because the msiexec process in Vista doesn't have the privilege you need you can install your own service that does have it. Use a deferred CA to talk with your service to have it do work for you (one call for install, and another for uninstall).
Even Office 2007 has its own service these days so why not you ;) Make sure that your service is manual startup! I'd hate to install your product and find my computer starts up slower because it wasted its processor time dedicated to this "temporary install helper" service.
I've done just this kind of pattern in the past. The requirement was a complete cleanup of registry keys on uninstall, including registry keys created in other users profiles per the current user pattern. The only real way to do this is to enumerate through the profiles, load the hives, whack the key and unload it.
I understand the stated reasons from Microsoft, but personally I disagree. I understand that an API was added to the SCM to allow for a registry value to specifiy a subset of rights for a running service. I don't have a problem with that. What I disagree with is WindowsInstaller actually implementing that registry value. I can see what many services would want to run with less rights, but the WindowsInstaller service needs all the rights because of the broad power installation and configuration really needs. To regression test the standard actions against the subset of rights and to say everyone else will be `unpleasently suprised` is not the correct way to go in my book.
Then again, it would be trivial for a bootstrapper to grant the right and bound MSIServer so ohwell..... moving on. For that matter you could whack the registry value then resume on reboot.
> I've done just this kind of pattern in the past. The requirement was a > complete cleanup of registry keys on uninstall, including registry keys > created in other users profiles per the current user pattern. The > only real way to do this is to enumerate through the profiles, load the > hives, whack the key and unload it.
> I understand the stated reasons from Microsoft, but personally I > disagree. I understand that an API was added to the SCM to allow for a > registry value to specifiy a subset of rights for a running service. I > don't have a problem with that. What I disagree with is > WindowsInstaller actually implementing that registry value. I can see > what many services would want to run with less rights, but the > WindowsInstaller service needs all the rights because of the broad > power installation and configuration really needs. To regression > test the standard actions against the subset of rights and to say > everyone else will be `unpleasently suprised` is not the correct way to > go in my book.
> Then again, it would be trivial for a bootstrapper to grant the right > and bound MSIServer so ohwell..... moving on. For that matter you > could whack the registry value then resume on reboot.
I actually agree with you but I think maybe it's hard for even the Microsoft folk themselves to fight the all important security mandate. Every single product/item for Vista has security enhancement as a primary feature.
Is there a better way for Microsoft to fix this? Yes. But because the number of people initially affected is small (not everyone needs absolute power custom actions) I think it will wait - maybe SP1?
For instance one better way is that they have two services registered -- one with absolute power and the other with more restricted access. The default "elevated" service used would be the restricted access version. To actually use the absolute power version some sort of Summary Information Stream property bit has to be set. A group policy preventing the use the absolute power service by default (to make security guys happy) allows administrator flexibility. If all bits and policies are aligned then the standard no-impersonate deferred CA would have absolute power -- otherwise same as today (not all powerful).
Meantime... we're all stuck without "absolute power" unless you use elevated bootstrapper hack (yuck) or service hack (yuck again).
"Christopher Painter" <chr...@yahoo.com> spake the secret code <1161294917.240439.22...@e3g2000cwe.googlegroups.com> thusly:
>Then again, it would be trivial for a bootstrapper to grant the right >and bound MSIServer so ohwell..... moving on. For that matter you >could whack the registry value then resume on reboot.
If the scenario of enumerating profiles is the one in question (the poster hasn't said yet), then I would solve this with a bootstrapper as you say. However, no reboot is needed. All you need to do is:
- use the Service API to stop the MSI service - modify the rights, saving the original settings - perform the install operation (the service will start automatically) - stop the MSI service - restore the saved settings
The service may not even be running, but the Service API will tell you if it is. Typically the service sits around live for about 15 minutes after you do an install operation and then exits if noone requests more install operations during that 15 minutes.
Its also important to save and restore the saved settings instead of resetting them to some fixed value. This preserves whatever settings changes may have been made by the administrator. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html>
> >Then again, it would be trivial for a bootstrapper to grant the right > >and bound MSIServer so ohwell..... moving on. For that matter you > >could whack the registry value then resume on reboot.
> If the scenario of enumerating profiles is the one in question (the > poster hasn't said yet), then I would solve this with a bootstrapper > as you say. However, no reboot is needed. All you need to do is:
> - use the Service API to stop the MSI service > - modify the rights, saving the original settings > - perform the install operation (the service will start automatically) > - stop the MSI service > - restore the saved settings
> The service may not even be running, but the Service API will tell you > if it is. Typically the service sits around live for about 15 minutes > after you do an install operation and then exits if noone requests more > install operations during that 15 minutes.
> Its also important to save and restore the saved settings instead of > resetting them to some fixed value. This preserves whatever settings > changes may have been made by the administrator. > -- > "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download > <http://www.xmission.com/~legalize/book/download/index.html>
Yes, I actually said it would be trivial for a boostrapper to grant the right and bounce MSIServer. When I talked about a reboot, I was talking about hitting the registry from within an MSI and then rebooting and resuming on startup to get the proper context.
The other thing that was crossing my mind was the SMS 2003 Advanced Client. I wonder what rights it is granted by default. If it gets the full set of privliges and you had a deferred CA with the noImpersonate bit *NOT set, would get get more rights then with the noImpersonate bit actually set? If so, isn't that ironic?
> If the scenario of enumerating profiles is the one in question (the > poster hasn't said yet), then I would solve this with a bootstrapper > as you say.
Yes, this is the scenario. We enumerate profiles for two reasons:
1. During an upgrade from an old version, we migrate settings from one "version key" tree to another (e.g. HKCU\Software\Motive\M-Files\3.0.1517.0 => HKCU\Software\Motive\M-Files\3.0.1518.0). This must be done for all users during the installation because the old version is typically uninstalled after the new version is successfully running. (Different builds of our software can cleanly run side-by-side so these version keys are required, we cannot simply continue using the old settings in the old keys.)
2. During uninstallation, we clean the registry settings from all users' profiles.
I understand the bootstrapper approach but it probably won't be acceptable to us. We want to allow administrators to deliver our installation as a single MSI file. Admins are often specifically requesting for an MSI file, they prefer it over an EXE. We do not want to require a reboot either.
We already have a helper EXE (Activator.exe) which we use for some CA operations. I guess it is best to convert that into a service so that it gets the required power.
From the security point of view, I don't really understand the benefit of this change in MSIEXEC. If we can circumvent the lack of SeBackupPrivilege this easily (i.e. install and start a service), then does removing this privilege from MSIEXEC really improve security so much that it is worth sacrificing installer compatibility?
I agree with Christopher on the nature of MSIEXEC: Since it is supposed to enable performing software installation, including system-level software, reducing its privileges in this way is not reasonable.
|
