coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

They restricted a lot of the privileges that are available to LOCALSYSTEM as a security precaution.... and no, they ain't gonna fix that (their response is, if you need to do that, write a service).

G

-----Original Message-----
From: Olaf van der Spek [mailto:olafvdspek@xxxxxxxxx] 
Sent: Monday, July 25, 2011 1:52 PM
To: Garrett Serack
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Changes to the design of CoApp

On Mon, Jul 25, 2011 at 10:46 PM, Garrett Serack <garretts@xxxxxxxxxxxxx> wrote:
>
> (posted on the coapp website at: 
> http://coapp.org/posts/2011/07/25/Changes-to-the-design-of-CoApp )
>
> On Friday, we had a conference call to discuss a critical problem in the CoApp package manager.
>
> ... when the user double-clicks on an a CoApp MSI, Windows Installer elevates the installer process by switching to the LOCALSYSTEM (NT AUTHORITY\SYSTEM) account, but actively removes a bunch of privileges that they didn’t figure an installer would need—specifically the ability to create symlinks has been removed. Symlinks are a critical part of CoApp’s design, and I’m not willing to compromise the features thatrely on them...
>
> Having looked at a few ways to overcome this limitation, we've pretty much settled on the idea that we will split up some of the CoApp components into finer-grained peices, and create a service that can perform the requisite high-privilige operations that are needed to for CoApp to manage packages correctly.

Hi Garrett,

Why does Windows Installer disallow this privilege? Would it be possible to get Windows Installer fixed not to do this?

Greetings,

Olaf