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 <[email protected]> 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 >> <[email protected]> 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 >>> [email protected] >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -- > Best regards, > Bulat mailto:[email protected] > > _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
