[Haskell-cafe] Cabal install on Windows 7

[Bulat Ziganshin]

Hello Peter,

Tuesday, September 15, 2009, 1:24:26 PM, you wrote:

in order to protect from viruses and so now windows programs should be
split into two parts - one that doesn't need admin privileges and one
that needs them. as far as your actions doesn't need second part, you
are running first program, when things haapened that needs admin
priv., second executable should be run and *OS* will ask whether yot
trust it. so it's pretty the same as sudo built-in in the system via
exe manifest files. with UAC enabled, you are never have admin
privileges while you run only first part of program

> It is possible for an executable with less privileges to
> "shellexecute" an executable that requires admin rights? Won't this
> immediately raise an "access denied" or other security exception
> again? Don't know, it might be possible, but it's worth to check it
> out before going this route (which is rather clever IMHO :)

> On Tue, Sep 15, 2009 at 10:14 AM, Regis Saint-Paul
> <regis.saint-paul at create-net.org> wrote:
>>
>>> > - use windows API for requesting elevation during the process (ugly)
>>>
>>> If it really has to be done, then this seems like the best approach. In
>>> principle there's no problem with calling funky win32 functions in
>>> Cabal, it's mostly a matter of working out what bahaviour we want and
>>> what UAC lets us do.
>>
>> To achieve this, a candidate solution would be:
>> - to have a separate executable with a manifest indicating that
>> administrator privilege are needed (and, ideally, signed) and able to
>> perform the tasks necessitating elevation
>> - from cabal, to run this separate process (calling shellexecute) exactly at
>> the point when elevation is needed
>> - alternatively, it might be possible to try the operation, catch the
>> exception that would happen if it fails, and call the separate process in
>> this case (see:
>> http://stackoverflow.com/questions/17533/request-vista-uac-elevation-if-path
>> -is-protected#17544)
>>
>> The advantage is that, with this solution, users only use "cabal" and the
>> elevation is performed when needed.
>>
>> By contrast, the other suggested solution of having two executables
>> (cabal-user and cabal-global) leaves the choice of elevating cabal to the
>> user and only needs to modify the build process (no code changed in cabal).
>> Its drawback is that elevation will be requested even when unnecessary every
>> time cabal-global is launched.
>>
>> So a first task would be to identify the cases where cabal needs to run with
>> elevated rights and the task to perform in that case.
>> - Is cabal going to be modified to use AppData for library install?
>> - If this is the case, then writing in protected folders would be only for
>> binary install (with cabal install). Are there other cases?
>> - If this is not the case, then writing in protected folder is for all
>> package install when in global mode...other cases?
>> - Am I missing operations where cabal would need admin privileges? For
>> instance, may cabal need to modify some environment variable?
>>
>> Cheers,
>> Regis
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com