[wix-users] Permission to Stop/Start a Service from a Custom Action on Button click

Thu May 31 01:01:30 PDT 2018

The blog post I was thinking about is for running a process in a different
session.

In general, you can start a new process with elevated privileges. You'd
need to carry another executable in the Binary table that does the real
work, extract that executable, and do the special mumble jumbo to elevate
the other process when you start it. And then you have to some how ensure
the user running the insralling the msi is an admin because if they are
not, then you can't elevate any ways as you'd need to request credentials
for an admin user. Still easier to use a deferred custom action.

--
Edwin G. Castro

On Thu, May 31, 2018, 00:23 Edwin Castro <egcastr at gmail.com> wrote:

> You are picking up the same identity in both cases but in the right click
> case your security token has been stripped of certain admin rights as
> implemented by UAC since Vista. In the elevated command prompt case your
> security token has already been elevated back to the full security token
> the admin user had prior to Vista. In the command prompt case the elevated
> security token is inherited from the elevated command prompt process while
> in the right click case the stripped security token is inherited from your
> explorer shell.
>
> You cannot run msiexec (or any process for that matter) with one security
> token (stripped) and change it to another (full) later on. This is a
> restriction implemented by the OS. You can start another process with a
> full security token with native APIs but that is not a trivial matter.
>
> When msiexec runs immediate custom actions in the UI sequence or the
> execute system, the immediate custom actions execute in a process that
> inherits the calling processes identity *and* security token. So they only
> run elevated if and only if the calling process is already elevated.
>
> Deferred custom actions are executed in a process that inherits the local
> system identity with a full security token. If the process then
> impersonates another user then its security token is also full. That is the
> reason why your custom actions must run deferred if you want to change the
> system. The only time your deferred custom actions might need impersonation
> is to access a resource that local system does not have access to (I'm
> mostly thinking network resources).
>
> That is a long way to say the user you're getting is correct un both cases
> but the privileges they have in their security token is different and you
> can't change it. You can start a new process with "stolen" security token
> but the process is explained in only one blog in the entire Internet
> without any sample code because the author didn't want to encourage people
> to do it. This the kind of stuff malware does to elevate privileges not
> what a well behaved application does. I don't think I have the bookmark to
> that blog post anymore either.
>
> --
> Edwin G. Castro
>
> On Wed, May 30, 2018, 22:07 Ven H via wix-users <
> wix-users at lists.wixtoolset.org> wrote:
>
>> Thanks a lot, Gerhard. You are right. Being an administrator on the
>> machine
>> does not mean that all processes will be launched elevated. But, within
>> the
>> custom action, how can we obtain the user. It should be different, when I
>> launch the msi from the command prompt as administrator using msiexec
>> command and when I right click on the msi and choose the Install option.
>> But in both the case, when I try to get the user using methods like
>> WindowsIdentity.GetCurrent(), I get the same user. May be, this is not the
>> right way, is there a way to get the user in the code?
>>
>> Regards,
>> Venkatesh
>>
>> On Wed, May 30, 2018 at 6:27 PM, Gerhard Matzen <gmatzen at osisoft.com>
>> wrote:
>>
>> > It sounds like you are not running the MSI elevated. You can convince
>> > yourself by verifying the “IngegrityLevel” in Process Explorer from the
>> > SysInternals suite.
>> >
>> >
>> >
>> > With user account control (UAC), being an administrator on the machine
>> > does not mean that all processes that you launch will be launched
>> elevated.
>> >
>> >
>> >
>> > *From:* Ven H <venh.123 at gmail.com>
>> > *Sent:* Wednesday, May 30, 2018 5:28 AM
>> > *To:* Gerhard Matzen <gmatzen at osisoft.com>
>> > *Cc:* WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
>> > *Subject:* Re: [wix-users] Permission to Stop/Start a Service from a
>> > Custom Action on Button click
>> >
>> >
>> >
>> > Thanks a lot. I am already an Administrator. That's why I am confused,
>> as
>> > to why it is not working.
>> >
>> >
>> > Regards,
>> > Venkatesh
>> >
>> >
>> >
>> > On Wed, May 30, 2018 at 5:51 PM, Gerhard Matzen <gmatzen at osisoft.com>
>> > wrote:
>> >
>> > You can make sure the user is privileged in a launch condition for the
>> MSI.
>> >
>> > <Condition Message="You must run this installation kit as administrator.
>> > If you are running on Vista/Server 2008 or greater, you must also run
>> the
>> > installation from an elevated command prompt.">Privileged</Condition>
>> >
>> > If you are worried about the "Programs and Features" Change/Modify
>> button
>> > not launching your MSI elevated, you should be able to set the
>> > NoElevateOnModify value in the registry.
>> > This DWORD goes under:
>> > "Software\Microsoft\Windows\CurrentVersion\Uninstall\YouAppName"
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of
>> Ven
>> > H via wix-users
>> > Sent: Wednesday, May 30, 2018 4:07 AM
>> > To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
>> > Cc: Ven H <venh.123 at gmail.com>
>> > Subject: [wix-users] Permission to Stop/Start a Service from a Custom
>> > Action on Button click
>> >
>> > I have a Custom Action that is called on a button click. In this button
>> > click, I have to restart the Sql Service on the local machine. After
>> > building this msi, if I right click and install, it fails while trying
>> to
>> > Stop & Start the service using ServiceController class (throws an access
>> > denied exception). I tried with the WMI approach also, but the same
>> result.
>> >
>> >  But if I open up a PowerShell or Console window as Administrator and
>> > execute the msi using msiexec command, it works fine. I am already an
>> > administrator in the machine. I am not able to understand why it doesn't
>> > work in the first case, whereas it works in the second case, even
>> though I
>> > am admin. How can I ensure in my Custom Action code to behave like the
>> > second case?
>> >
>> > I tried with and without Impersonate attributes on the Custom Action,
>> but
>> > no luck. Since it is called on button click, I am not able to make the
>> CA
>> > deferred and hence it is immediate. In my CA code, when I check the
>> current
>> > user using Environment.GetEnvironmentVariable("USERNAME") and also using
>> > System.Security.Principal.WindowsIdentity.GetCurrent(), it shows the
>> same
>> > in both the cases. I am a little confused. Can anyone please help me?
>> >
>> > ____________________________________________________________________
>> > WiX Toolset Users Mailing List provided by FireGiant
>> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.
>> > firegiant.com_&d=DwICAg&c=rxxrGm2iek7pTJSSe1mAiw&r=8MUQEKTKe_
>> > mBRfow6NKhbaPfXB9hL3W80bUJJehenQg&m=7jX_Lv6a4BSknM5oq_
>> >
>> ZBaIoZMunArGzbAGk3wLYx2kg&s=lYzG1l7Ev3LfBTMXMy4Zfj7WaYfCV0f3OJ9Kd9Cm8_Y&e=
>> >
>> >
>> >
>>
>> ____________________________________________________________________
>> WiX Toolset Users Mailing List provided by FireGiant
>> http://www.firegiant.com/
>
>