Vista: How to get SeBackupPrivilege in a deferred custom action EXE?
Antti Nivala
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?
Thanks in advance!
Antti
Gary Chang[MSFT]
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:
General Windows Vista Development Issues
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=120&SiteID=1
Application Compatibility for Windows Vista
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=904&SiteID=1
Thanks!
Best regards,
Gary Chang
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
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.
chrpai
This *IS* a WindowsInstaller issue:
I found this article:
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Vista_Services.doc
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.
SeTcbPrivilege
SeCreatePagefilePrivilege
SeLockMemoryPrivilege
SeIncreaseBasePriorityPrivilege
SeCreatePermanentPrivilege
SeAuditPrivilege
SeSecurityPrivilege
SeChangeNotifyPrivilege
SeProfileSingleProcessPrivilege
SeImpersonatePrivilege
SeCreateGlobalPrivilege
SeAssignPrimaryTokenPrivilege
SeRestorePrivilege
SeIncreaseQuotaPrivilege
SeShutdownPrivilege
SeTakeOwnershipPrivilege
SeLoadDriverPrivilege
chrpai
http://chrpai.blogspot.com/2006/10/vista-deferred-ca-consideration.html
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.
Antti Nivala
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?
Antti
chrpai
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.
Christopher Painter
Antti-
Can you confirm if changing the registry setttings for the MsiServer
service and restarting the service cured your rights problem?
I've brought this up during the MSI UAC webcast today and the
WindowsInstaller team is going to look into it.
Antti Nivala
> service and restarting the service cured your rights problem?
I haven't tried that yet but I will check it and let you know by tomorrow.
> I've brought this up during the MSI UAC webcast today and the
> WindowsInstaller team is going to look into it.
Great, many thanks!
Antti
Christopher Painter
Sorry, I think your out of luck.
Richard [Microsoft Windows Installer MVP]
"Antti Nivala" <niv...@newsgroup.nospam> spake the secret code
<uJ6RiCJ7...@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?
That is the best practice for modifying the registry, not a custom action.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Adrian Accinelli
"Richard [Microsoft Windows Installer MVP]"
<legaliz...@mail.xmission.com> wrote in message
news:uf4uC978...@TK2MSFTNGP05.phx.gbl...
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.
Sincerely,
Adrian Accinelli
Christopher Painter
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.
Adrian Accinelli
"Christopher Painter" <chr...@yahoo.com> wrote in message
news:1161294917....@e3g2000cwe.googlegroups.com...
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).
Sincerely,
Adrian Accinelli
Richard [Microsoft Windows Installer MVP]
"Christopher Painter" <chr...@yahoo.com> spake the secret code
<1161294917....@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.
Christopher Painter
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?
Antti Nivala
> 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.
Antti