SQL Server 2005 has a very extensive security model of its own. In order to
drop a database, the connecting account needs CONTROL permission on the
database. This permission is automatically granted to the database owner and
implicitly to members of the sysadmin server role (CONTROL on a database is
implied by CONTROL SERVER permission on the server). The
BUILTIN\Administrators Windows security group is by default a member of the
sysadmin server role. On Windows Vista the membership of this group is only
expressed in the privileged token accessed through UAC, not in the
low-privilege token.
The modifying SQL custom actions are all executed deferred and impersonated.
(As always, the custom tables built by the compiler are read and turned into
appropriate deferred custom action data by the immediate actions, but the
actual operations are performed by deferred actions as part of the
installation transaction.) My understanding of the installation process
under UAC was that even the create actions would not be elevated - are you
testing by running from an elevated command prompt? I believe this will
cause impersonated actions to be elevated.
If you turned impersonation off this would help you for the local
installation case - as the action then runs as LocalSystem, which is a
member of BUILTIN\Administrators - but doesn't help for installation on a
remote SQL Server, which some users of WiX may need (as LocalSystem
authenticates as the machine on a domain network, but has no network
credentials in a workgroup).
That really leaves specifying a SQL Server login to connect, but this is
turned off by default in the SQL Server Express installer and not
recommended in full SQL Server as the password is sent 'in the clear'. It's
only encrypted if the whole connection is encrypted, which requires that the
server has an SSL certificate installed. Many sites may not want to enable
SQL Server Authentication.
I'm not sure there's a simple solution, because Windows Installer doesn't
offer a way to impersonate any other user. I'm rapidly concluding that you
can't reliably install SQL databases from Windows Installer. Any competent
DBA will want to control layout of files on the database server's disks
anyway. I think the best approach is to ship scripts and leave it up to the
DBA to create the database. That's the approach I'm taking.
Another approach would be to provide the database as a separate feature, so
that the DBA or other administrator could run the MSI on the database server
itself to install the database.
Microsoft's recommendation with SQL Server Express is to use the common
SQLEXPRESS instance and use the database attach feature, that is, specifying
AttachDBFilename or Initial File Name in the connection string. The database
file is then only associated with the database server when the connection is
open. This might be a good option if you don't need to support a remote SQL
Server.
If you have a relatively low-spec database you could also consider SQL
Server Compact Edition, which is file-based and in-process (there is no
actual server). It's very limited on SQL syntax and datatype support,
though.
Extension idea:
There's no reason a custom action couldn't call LogonUser and
ImpersonateLoggedOnUser to change who it's running as. (If it's not
impersonated already, it's running as LocalSystem which has the TCB
privilege necessary to call LogonUser on Windows 2000.) It could be possible
to ask for alternate Windows login credentials to run these actions. You
would have to be careful to call RevertToSelf on all possible exit paths to
ensure that further custom actions using the same server process would run
with the correct credentials, however.
--
Mike Dimmick
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sajo Jacob
Sent: 23 March 2008 04:46
To: Bob Arnson
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiXSqlExtension issue on Vista with UAC
SQL Server 2005 Express. In fact this issue also causes the Repair scenario
to fail.
Jacob
On Sat, Mar 22, 2008 at 1:29 PM, Bob Arnson <[EMAIL PROTECTED]> wrote:
Sajo Jacob wrote:
If it is by design, then there is a problem with using WiXSqlExtension for
creating an installer for Vista/WS2008 because the uninstallation will fail
is you attempt to uninstall the product from Add/remove programs because the
custom actions to drop the database is getting executed as immediate, unless
you make the users use an elevated command prompt and manually uninstall the
product. (if you created a database using WiXSqlExtension and have
sqlstrings to drop the database.)
Which SQL server are you using? The general case is that the server itself
has the permissions needed to manipulate the file system.
--
sig://boB
http://joyofsetup.com/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
