Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

cooperation with Windows Vista's User Access Control #313

Closed
bos opened this Issue May 24, 2012 · 13 comments

Comments

Projects
None yet
3 participants
Contributor

bos commented May 24, 2012

(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)
Contributor

bos commented May 24, 2012

(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!

Contributor

bos commented May 24, 2012

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

Contributor

bos commented May 24, 2012

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

Contributor

bos commented May 24, 2012

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

Contributor

bos commented May 24, 2012

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

Contributor

bos commented May 24, 2012

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

See also #465.

Contributor

bos commented May 24, 2012

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

Contributor

bos commented May 24, 2012

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

Contributor

bos commented May 24, 2012

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

tibbe commented May 1, 2013

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.

@tibbe tibbe closed this May 1, 2013

Member

23Skidoo commented May 1, 2013

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

Owner

tibbe commented May 1, 2013

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

Member

23Skidoo commented May 1, 2013

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment