Re[2]: [Haskell-cafe] Cabal install on Windows 7

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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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