Security differences between MSIEXEC 1.1 and 2.0

[Conor Maguire]

Hi all,

I need to populate HKCU keys from a CA for accounts already on a box. I've
hit the following problem. Any general comments on this? Any workaround
suggestions?

thanks,

Conor.

I am using a WinAPI function RegLoadKey to load a user's hive stored in
their NTUSER.DAT into the registry. This function just loads the hive into
the registry and then I apply changes to the hive saved in the registry by
using the standard WinAPI registry functions and then I call another
function called RegUnLoadKey to save this hive out back to the user's
NTUSER.DAT.

As part of the documentation for the RegLoadKey function it says that the
calling process must have the privilege SE_RESTORE_NAME or
SeRestorePrivilege for this function to succeed. So, this privilege must be
set in the calling process , in this instance msiexec.exe, to allow for
RegLoadKey to work. From developing this function into a Custom Action I
wrote some code that queries what privileges a process has. Below is what I
discovered:

MsiExec Version 2.00.2600.0 privileges:

SeChangeNotifyPrivilege

SeUndockPrivilege

SeIncreaseQuotaPrivilege

SeLoadDriverPrivilege

SeShutdownPrivilege

MsiExec Version 1.10.1029.0 privileges:

SeChangeNotifyPrivilege

SeSecurityPrivilege

SeUndockPrivilege

SeRestorePrivilege

SeIncreaseQuotaPrivilege

SeShutdownPrivilege

SeLoadDriverPrivilege

SeTakeOwnershipPrivilege

As the SeRestorePrivilege privilege is available in Version 1.10.1029.0 the
function RegLoadKey worked fine when this privilege was enabled and as it is
not available in Version 2.00.2600.0 an error 1314
(ERROR_PRIVILEGE_NOT_HELD) is returned when the RegLoadKey function is
called as this privilege can not be enabled as it's not part of the calling
process's (MsiExec Version 1.10.1029.0) privileges.

[Dennis Schmidt]

Hi Conor,

My name is Dennis Schmidt. Thank you for using the Microsoft Windows
Installer Newsgroups.

I believe that your problem is that your CA is running in
InstallExecuteSequence table. What happens when this is the case is that
it does not run until it goes over to the service side of MSIExec. When
executing from the service, the token privileges of the service are passed
on to the new process which are more limited than when running as normal
win32 user process.

So, workaround is to launch the CA as type 50 or 114 from the
InstallUISequence table. This causes the CA to run under the client side
of MSIExe much the same as any other win32 user process. The only down
side to this process is that CA's in the InstallUISequence table do not run
during a silent install.

I hope this helps! If you have additional questions on this topic, please
reply to this posting.

Need quick answers to questions like these? The Microsoft Knowledge Base
provides a wealth of information that you can use to troubleshoot a problem
or answer a question! It's located at
http://support.microsoft.com/support/c.asp?M=F>.

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2001 Microsoft Corporation. All rights
reserved.

Regards,
Dennis Schmidt
Microsoft Support

[Darwin]

Conor,
Are you aware that Windows Installer has built-in support for propagating
User Registry keys to existing hives when the user attempts to use the
application the first time? Essentially it is self-healing the user
portions of the application. If the feature/component structure is correct
it happens automatically and since it only happens on an as needed, per-user
basis the user who is about to use the application is logged in and has
rights to change their own registry hive.
D.

--
__________________________
Darwin Sanoy
Principal Consultant
DesktopEngineer.com
Windows Installer for Administrators Training
Windows Installer Certification
http://windowsinstallertraining.com

"Conor Maguire" <cono...@hotmail.com> wrote in message
news:icZh9.7$kM4.1...@news.cpqcorp.net...

[Conor Maguire]

Hi Dennis,
thanks for the reply. Unfortunately, all the packages must run qb- so
the InstallUI Sequence is out of the picture. Either way, I'm loathe to
modify the machine during the InstallUI. Any official word from MS on why
the security differences between the versions?

thanks,
Conor.

btw. further info in response to Darwin..

"Dennis Schmidt" <Dennis...@microsoft.com> wrote in message
news:iVKXhCyXCHA.1632@cpmsftngxa08...

[Conor Maguire]

Hi Darwin,
thanks for that. The problem I have is that this app has no entry points
exposed to the user (its an add-in for Excel). I've hacked together
something using the RunOnce key. Its a bit nasty and it would be infinitely
preferable to have a Windows Installer-based solution.

cheers,
Conor.

"Darwin" <n...@spam.for.me.com> wrote in message
news:eJwbAeyXCHA.1748@tkmsftngp09...

[Darwin]

If you can find a way to wait until the user logs on you could setup
something to run msiexec /fu {product code} /qb to silently force the user
registry keys down.

Fyi,
D.

--
__________________________
Darwin Sanoy
Principal Consultant
DesktopEngineer.com
Windows Installer for Administrators Training
Windows Installer Certification
http://windowsinstallertraining.com

"Conor Maguire" <cono...@hotmail.com> wrote in message

news:07Gj9.13$am2.4...@news.cpqcorp.net...