Yes, I'm aware of that, but not the details, so thanks for the info.
Anyway, I quickly tested Regis's idea in C#, and it works as he said.
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=9392#a9392
- When trying to create a folder in ProgramFiles, you get an access
denied exception, unless the program is run as admin.
- When trying to "shellexec" a program requiring admin rights - in
this case regedit.exe - you get a popup, unless run as admin
So this looks like a really clever & simple solution :-)
On Tue, Sep 15, 2009 at 11:49 AM, Bulat Ziganshin
<bulat.ziganshin at gmail.com> wrote:
> 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>>