cooperation with Windows Vista's User Access Control

[Toxaris]

Installation of a cabal package under Windows Vista with UAC activated may fail even when working as administrator, because cabal doesn't request the necessary rights to write to, e.g., "c:\Program Files\Haskell\<whatever>". A workaround is to start an "Administrator console" to start Cabal from a process which already acquired admin privileges.

Cabal should request the necessary rights instead of failing.

cabal-install should check in advance whether the target destination is writeable and fail early or request the necessary rights. (currently, cabal-install fails after compiling all dependencies. After starting cabal-install again from an Administrator console, everything has to be build again).

C:\Downloads\Haskell\typeof-0.1.1>runhaskell Setup install
Setup: C:\Program Files\Haskell\doc\typeof-0.1.1: copyFile: permission denied (P
ermission denied)

[duncan]

If anyone has any suggestion on what we actually do to check write permission or request the necessary rights, please chip in!

[eipi]

It seems the most convenient solution for elevating a process using win32 would be to run that process through ShellExecuteEx?. The trick is that a new verb can be used in the SHELLEXECUTEINFO struct (field "lpVerb"), setting it with value "runas". If started in this way, the process will display the UAC dialog for authorization instead of failing. So for Cabal, it seems the copy and dir creation could be handled by spawning a new process using the win32 API as descibed above.

[br1]

In my opinion, things should be left as they are. Requiring running cabal from an elevated cmd.exe is the right way. There are sudo like tools for Vista, for example:  http://www.wintellect.com/cs/blogs/jrobbins/archive/2007/03/27/elevate-a-process-at-the-command-line-in-vista.aspx

If the user is non admin, he installed GHC outside Program Files. He can't run Cabal if it requires elevated permissions.

If the user IS an admin, he still may have installed GHC outside Program Files. UAC prompts are unnecessary and annoying.

[Toxaris]

My ghcs are installed in c:\ghc. I don't think that their location is relevant to the issue at hand.

I don't think that I set the path "c:\program files\Haskell" for cabal-installed stuff manually. I guess it is the default path. If cabal can not work together with the (maybe stupid) OS mechanisms to protect "c:\program files", it should avoid using this path by default.

Of course, cabal should not display a UAC prompt unnecessarily. But displaying a UAC prompt when necessary is clearly superior to failing, and seems to be in the spirit of the UAC.

[duncan]

Assigning to milestone _|_ because it needs more investigation before we can proceed.

We do not yet have a very clear description of the problem or the solution. How do we know when we need to ask for more permissions? If we do know, how exactly do we ask?

Are there better alternatives like doing per-user installs rather than global installs by default. What is the appropriate location for per-user library and application installs.

[duncan]

See also #465.

[br1]

FWIW, I asked Microsoft:

Hi. I've been tracking some Haskell issues regarding permissions in Vista. Haskell includes a package manager for its libraries. It's not clear what the UAC story is for this. It's not right for the package manager to request admin privileges, because it forbids non-admin users to install a private version of the Haskell tools. Maybe you could take a look:  http://hackage.haskell.org/trac/hackage/ticket/320#comment:5

This is the response:

I'm not familiar with the tool or how it works. If you're creating a pure per-user application, then simply writing the files to a per-user location is sufficient. If you're looking for a per-machine install, you can use MSI Patches to upgrade without requiring admin rights, as described here:  http://msdn.microsoft.com/en-us/library/aa370582(VS.85).aspx. I generally advise not trying to replicate the AccessCheck? logic and elevate accordingly - it's too easy to get that wrong. Rather, just factor the application, and always elevate or never elevate (if it's per-user).

[duncan]

Replying to br1:

FWIW, I asked Microsoft:

Heh, thanks.

I'm not familiar with the tool or how it works. If you're creating a pure per-user application, then simply writing the files to a per-user location is sufficient.

I'm sure this is the most sensible default (#465). It's not clear if there is any default per-user location that we should use. I think currently for --user installs on Windows we use the per-user app-data area, which I think is mainly intended for data files rather than programs.

I looked up per-user installs with MSI  http://msdn.microsoft.com/en-us/library/aa370813(VS.85).aspx but it's not clear that there is any per-user area for program files. The program files directory seems to be only globally shared.

I generally advise not trying to replicate the AccessCheck logic and elevate accordingly - it's too easy to get that wrong. Rather, just factor the application, and always elevate or never elevate (if it's per-user).

This also sounds very sensible.

[duncan]

According to  this MSDN article we have to use ShellExecute() to be able to run a separate helper program that has a manifest that says it needs admin priviledges. It's either that or making an out-of-process COM component that runs with higher privilege.

Using the ordinary CreateProcess() will fail. Apparently ShellExecute() catches the error and goes off and talks to some service to launch the program on our behalf. In turn that service pops up a UAC prompt. Apparently we cannot just talk directly to that service (at least there's no documentation on it), we have to go via ShellExecute().

The  ShellExecute() API is pretty horrible. For one thing it requires that you initialise COM. It's also full of string verbs and usless stuff related to documents and window visibility.

I think what we should do is:

• Use per-user installs by default
• If the user does a --global install, check that we are running with administrator credentials and if not present a sensible error message. In particular this means not just an admin user, but running already with elevated privileges. That effectively means it must be run from within an elevated console window.

See the section for console applications in  this MSDN article.

[elga]

*  simyo