cooperation with Windows Vista's User Access Control

[bos]

(Imported from Trac #320, reported by @toxaris on 2008-08-05)

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)

[bos]

(Imported comment by @dcoutts on 2008-08-05)

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

[bos]

(Imported comment by eipi on 2008-08-06)

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.

[bos]

(Imported comment by br1 on 2008-10-10)

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.

[bos]

(Imported comment by @toxaris on 2008-10-11)

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.

[bos]

(Imported comment by @dcoutts on 2009-01-27)

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.

[bos]

(Imported comment by @dcoutts on 2009-03-03)

See also #465.

[bos]

(Imported comment by br1 on 2009-03-03)

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).

[bos]

(Imported comment by @dcoutts on 2009-03-04)

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.

[bos]

(Imported comment by @dcoutts on 2009-03-04)

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](http://msdn.microsoft.com/en-us/library/bb756922.aspx).

[tibbe]

Vista has a small market share nowadays and no one has expressed interest in this bug in several years so I'm going to close it. If it affects you, let me know.

[23Skidoo]

@tibbe

Vista has a small market share nowadays

Are you sure that this affects only Vista and not any version of Windows > XP? Also, we now use per-user installs by default so this should be less of a problem.

[tibbe]

@23Skidoo Not sure, I expect someone to pipe up if this is still a problem.

[23Skidoo]

@tibbe Should be only a problem when using cabal install --global.