Cabal install on Windows 7

Peter Verswyvelen

8 Sep 2009 8 Sep '09

9:31 a.m.

I tried the "cabal install" command on Windows 7, and I had to run it with administrative privileges, otherwise I got access denied (it failed to create the Haskell folder in C:\Program Files) Not sure if this is also the case on Vista. Is this the intended behavior?

Show replies by date

John Van Enk

8 Sep 8 Sep

9:45 a.m.

Might it make sense to try and get the concept of "global" and "user" working in Windows? (It may already, but I noticed that the default seems to be global.") I don't know what technical challenges there are, but the ApplicationData directory (or AppData, or whatever) seems like a good place to stick user cabal packages. /jve On Tue, Sep 8, 2009 at 9:31 AM, Peter Verswyvelen wrote:

...

I tried the "cabal install" command on Windows 7, and I had to run it with administrative privileges, otherwise I got access denied (it failed to create the Haskell folder in C:\Program Files)

Not sure if this is also the case on Vista.

Is this the intended behavior? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Peter Verswyvelen

10:17 a.m.

Ouch, right, I forgot the default is global. It works fine with cabal install --user. And of course I could have edited the default config file, setting user-install: True Well, maybe for newbies this might be a bit confusing. Typically, under Windows Vista or 7 when you try to install something that requires admin rights, you get a popup window asking if it's okay to do so. Would be great to have this support built into Cabal? On Tue, Sep 8, 2009 at 3:45 PM, John Van Enk wrote:

...

Might it make sense to try and get the concept of "global" and "user" working in Windows? (It may already, but I noticed that the default seems to be global.")

I don't know what technical challenges there are, but the ApplicationData directory (or AppData, or whatever) seems like a good place to stick user cabal packages.

/jve

On Tue, Sep 8, 2009 at 9:31 AM, Peter Verswyvelen wrote:

...
I tried the "cabal install" command on Windows 7, and I had to run it with administrative privileges, otherwise I got access denied (it failed to create the Haskell folder in C:\Program Files)

Not sure if this is also the case on Vista.

Is this the intended behavior? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Jeff Wheeler

10:58 a.m.

On Tue, Sep 8, 2009 at 9:17 AM, Peter Verswyvelen wrote:

...

Ouch, right, I forgot the default is global. It works fine with cabal install --user. And of course I could have edited the default config file, setting user-install: True

Well, maybe for newbies this might be a bit confusing.

Yep, I agree. I'm not sure why Cabal defaults to --global on Windows, but I found it quite counter-intuitive having come from a Linux environment. I forgot about the different default for some time. Jeff Wheeler

Duncan Coutts

9 Sep 9 Sep

8:28 a.m.

On Tue, 2009-09-08 at 09:58 -0500, Jeff Wheeler wrote:

...

On Tue, Sep 8, 2009 at 9:17 AM, Peter Verswyvelen wrote:

...
Ouch, right, I forgot the default is global. It works fine with cabal install --user. And of course I could have edited the default config file, setting user-install: True

Well, maybe for newbies this might be a bit confusing.

Yep, I agree. I'm not sure why Cabal defaults to --global on Windows, but I found it quite counter-intuitive having come from a Linux environment. I forgot about the different default for some time.

It was because last time we discussed this, the Windows users seemed to be of the opinion that things were simpler with global installs since the %PATH% would be right by default and "everyone runs as Administrator anyway". That may well be different now. If the Windows users can come to a consensus on whether the default should be global or user, then we can easily switch it. The same applies for the default global or user installation paths. If there are any Windows users who understand the Windows permissions system then the Cabal hackers would appreciate some help. As it is the Cabal hackers have no access to Vista or Win7 and cannot test what is actually going on with Windows permissions or pop-up windows prompting whether it's ok to do this or that. Duncan

Peter Verswyvelen

10:59 a.m.

Yes, it's true that most people tended to be administrators on their own Windows desktops, but since Vista, this has changed. Now in Vista, some people still forced admin rights, to get rid of the many annoying dialog boxes that popped up for every tiny task that might be a security breach. But it seems that under Windows 7 this is less intrusive, so we might consider having the Haskell Platform work well by default without assuming admin rights? Or at least the installer should clearly tell you about it, or provide an option. On Wed, Sep 9, 2009 at 2:28 PM, Duncan Coutts wrote:

...

On Tue, 2009-09-08 at 09:58 -0500, Jeff Wheeler wrote:

...
On Tue, Sep 8, 2009 at 9:17 AM, Peter Verswyvelen wrote:

...
Ouch, right, I forgot the default is global. It works fine with cabal install --user. And of course I could have edited the default config file, setting user-install: True

Well, maybe for newbies this might be a bit confusing.

Yep, I agree. I'm not sure why Cabal defaults to --global on Windows, but I found it quite counter-intuitive having come from a Linux environment. I forgot about the different default for some time.

It was because last time we discussed this, the Windows users seemed to be of the opinion that things were simpler with global installs since the %PATH% would be right by default and "everyone runs as Administrator anyway". That may well be different now.

If the Windows users can come to a consensus on whether the default should be global or user, then we can easily switch it. The same applies for the default global or user installation paths.

If there are any Windows users who understand the Windows permissions system then the Cabal hackers would appreciate some help. As it is the Cabal hackers have no access to Vista or Win7 and cannot test what is actually going on with Windows permissions or pop-up windows prompting whether it's ok to do this or that.

Duncan

Duncan Coutts

11:39 a.m.

On Wed, 2009-09-09 at 16:59 +0200, Peter Verswyvelen wrote:

...

Yes, it's true that most people tended to be administrators on their own Windows desktops, but since Vista, this has changed.

Now in Vista, some people still forced admin rights, to get rid of the many annoying dialog boxes that popped up for every tiny task that might be a security breach.

But it seems that under Windows 7 this is less intrusive, so we might consider having the Haskell Platform work well by default without assuming admin rights? Or at least the installer should clearly tell you about it, or provide an option.

It's always been my view that it should work without admin privileges. It's only been very recently that I've had access to a Windows installation where I am admin. What you need to do is to get the Windows users to agree on what the sensible defaults should be. If you conclude that actually it needs something more complicated like interacting with Windows UAC or something then we'll need to find a volunteer Windows hacker who can implement it. The situation we have at the moment is people complaining but nobody taking action. Duncan

Sebastian Sylvan

3:19 p.m.

On Wed, Sep 9, 2009 at 1:28 PM, Duncan Coutts wrote:

...

On Tue, 2009-09-08 at 09:58 -0500, Jeff Wheeler wrote:

...
On Tue, Sep 8, 2009 at 9:17 AM, Peter Verswyvelen wrote:

...
Ouch, right, I forgot the default is global. It works fine with cabal install --user. And of course I could have edited the default config file, setting user-install: True

Well, maybe for newbies this might be a bit confusing.

Yep, I agree. I'm not sure why Cabal defaults to --global on Windows, but I found it quite counter-intuitive having come from a Linux environment. I forgot about the different default for some time.

It was because last time we discussed this, the Windows users seemed to be of the opinion that things were simpler with global installs since the %PATH% would be right by default and "everyone runs as Administrator anyway". That may well be different now.

If the Windows users can come to a consensus on whether the default should be global or user, then we can easily switch it. The same applies for the default global or user installation paths.

I think it's morally right to run as user by default. Yes, the windows culture has some legacy that may, on occasion, make it slightly harder to use "well behaved" programs, but it's fairly minor these days. -- Sebastian Sylvan

Jeff Wheeler

10:18 p.m.

On Wed, Sep 9, 2009 at 2:19 PM, Sebastian Sylvan wrote:

...

I think it's morally right to run as user by default. Yes, the windows culture has some legacy that may, on occasion, make it slightly harder to use "well behaved" programs, but it's fairly minor these days.

I strongly agree. Presently, on Windows 7, I have to right-click and "Run As Administrator" and then approve the process via UAC to get anything done under the default --global setting, in much the same way I would have to launch a root terminal and provide my password within GNOME (a la gksu) or other *nix environments (Windows doesn't have anything like sudo, as far as I know). Since it works essentially the same as *nix does, as of Windows 7, I see no reason for a different default. Jeff Wheeler

Peter Verswyvelen

10 Sep 10 Sep

5:21 a.m.

Actually, this UAC was already present in Vista no? On Thu, Sep 10, 2009 at 4:18 AM, Jeff Wheeler wrote:

...

On Wed, Sep 9, 2009 at 2:19 PM, Sebastian Sylvan wrote:

...
I think it's morally right to run as user by default. Yes, the windows culture has some legacy that may, on occasion, make it slightly harder to use "well behaved" programs, but it's fairly minor these days.

I strongly agree. Presently, on Windows 7, I have to right-click and "Run As Administrator" and then approve the process via UAC to get anything done under the default --global setting, in much the same way I would have to launch a root terminal and provide my password within GNOME (a la gksu) or other *nix environments (Windows doesn't have anything like sudo, as far as I know).

Since it works essentially the same as *nix does, as of Windows 7, I see no reason for a different default.

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

Peter Verswyvelen

5:25 a.m.

Interestingly, a sudo for Windows does seem to exist. It's called the "runas" command. At first sight it existed already since Windows XP Also on Sourceforge an open source sudo command for Windows is hosted: http://sourceforge.net/projects/sudowin On Thu, Sep 10, 2009 at 11:21 AM, Peter Verswyvelen wrote:

...

Actually, this UAC was already present in Vista no?

On Thu, Sep 10, 2009 at 4:18 AM, Jeff Wheeler wrote:

...
On Wed, Sep 9, 2009 at 2:19 PM, Sebastian Sylvan wrote:

...
I think it's morally right to run as user by default. Yes, the windows culture has some legacy that may, on occasion, make it slightly harder to use "well behaved" programs, but it's fairly minor these days.

I strongly agree. Presently, on Windows 7, I have to right-click and "Run As Administrator" and then approve the process via UAC to get anything done under the default --global setting, in much the same way I would have to launch a root terminal and provide my password within GNOME (a la gksu) or other *nix environments (Windows doesn't have anything like sudo, as far as I know).

Since it works essentially the same as *nix does, as of Windows 7, I see no reason for a different default.

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

Duncan Coutts

6:53 a.m.

On Wed, 2009-09-09 at 21:18 -0500, Jeff Wheeler wrote:

...

On Wed, Sep 9, 2009 at 2:19 PM, Sebastian Sylvan wrote:

...
I think it's morally right to run as user by default. Yes, the windows culture has some legacy that may, on occasion, make it slightly harder to use "well behaved" programs, but it's fairly minor these days.

I strongly agree. Presently, on Windows 7, I have to right-click and "Run As Administrator" and then approve the process via UAC to get anything done under the default --global setting

And when you switch the default to user installs (by editing the config file) does everything work ok then? I'm trying to work out if we switch the "default default", if it'll just work, or if there are further problems to solve. Duncan

Duncan Coutts

5:58 a.m.

On Wed, 2009-09-09 at 20:19 +0100, Sebastian Sylvan wrote:

...

On Wed, Sep 9, 2009 at 1:28 PM, Duncan Coutts wrote:

...

If the Windows users can come to a consensus on whether the default should be global or user, then we can easily switch it. The same applies for the default global or user installation paths.

...

I think it's morally right to run as user by default. Yes, the windows culture has some legacy that may, on occasion, make it slightly harder to use "well behaved" programs, but it's fairly minor these days.

So is it just a matter of switching the default, or do the default user paths have to change too? Is there any recommended/sensible place for installing per-user applications on Windows? (I think there wasn't on XP, but perhaps that's changed on Vista/Win7) Have you tried running with user as the default for a while? Does it work ok? Duncan

Sebastian Sylvan

6:39 a.m.

On Thu, Sep 10, 2009 at 10:58 AM, Duncan Coutts

...

wrote:

...

On Wed, 2009-09-09 at 20:19 +0100, Sebastian Sylvan wrote:

...
On Wed, Sep 9, 2009 at 1:28 PM, Duncan Coutts wrote:

...
If the Windows users can come to a consensus on whether the default should be global or user, then we can easily switch it. The same applies for the default global or user installation paths.

...
I think it's morally right to run as user by default. Yes, the windows culture has some legacy that may, on occasion, make it slightly harder to use "well behaved" programs, but it's fairly minor these days.

So is it just a matter of switching the default, or do the default user paths have to change too? Is there any recommended/sensible place for installing per-user applications on Windows? (I think there wasn't on XP, but perhaps that's changed on Vista/Win7)

I think it's %LOCALAPPDATA% -- Sebastian Sylvan

Deniz Dogan

7:16 a.m.

2009/9/10 Sebastian Sylvan :

...

On Thu, Sep 10, 2009 at 10:58 AM, Duncan Coutts wrote:

...
On Wed, 2009-09-09 at 20:19 +0100, Sebastian Sylvan wrote:

...
On Wed, Sep 9, 2009 at 1:28 PM, Duncan Coutts wrote:

...
If the Windows users can come to a consensus on whether the default should be global or user, then we can easily switch it. The same applies for the default global or user installation paths.

...
I think it's morally right to run as user by default. Yes, the windows culture has some legacy that may, on occasion, make it slightly harder to use "well behaved" programs, but it's fairly minor these days.

So is it just a matter of switching the default, or do the default user paths have to change too? Is there any recommended/sensible place for installing per-user applications on Windows? (I think there wasn't on XP, but perhaps that's changed on Vista/Win7)

I think it's %LOCALAPPDATA%

-- Sebastian Sylvan

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

Is there any %LOCALAPPDATA% on Windows XP? If not, what is the difference between %LOCALAPPDATA% and %APPDATA% in Windows Vista/7? I was thinking if it's not unreasonable to store Cabal stuff in %APPDATA%, one might as well use that and cover XP, Vista and 7 all in one. -- Deniz Dogan

Peter Verswyvelen

8:26 a.m.

No Windows XP did not have support for roaming profiles yet I think. But it wouldn't be too difficult to use %LOCALAPPDATA% first, and when it doesn't exist, use %APPDATA%? This article explains a lot about the differences; I didn't have time yet to read it in detail http://technet.microsoft.com/en-us/library/cc766489(WS.10).aspx What other software sometimes does (like Autodesk Maya), is just create a folder in the "My Documents" logical folder. I personally don't like this. On Thu, Sep 10, 2009 at 1:16 PM, Deniz Dogan wrote:

...

2009/9/10 Sebastian Sylvan :

...
On Thu, Sep 10, 2009 at 10:58 AM, Duncan Coutts wrote:

...
On Wed, 2009-09-09 at 20:19 +0100, Sebastian Sylvan wrote:

...
On Wed, Sep 9, 2009 at 1:28 PM, Duncan Coutts wrote:

...
If the Windows users can come to a consensus on whether the default should be global or user, then we can easily switch it. The same applies for the default global or user installation paths.

...
I think it's morally right to run as user by default. Yes, the windows culture has some legacy that may, on occasion, make it slightly harder to use "well behaved" programs, but it's fairly minor these days.

So is it just a matter of switching the default, or do the default user paths have to change too? Is there any recommended/sensible place for installing per-user applications on Windows? (I think there wasn't on XP, but perhaps that's changed on Vista/Win7)

I think it's %LOCALAPPDATA%

-- Sebastian Sylvan

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

Is there any %LOCALAPPDATA% on Windows XP? If not, what is the difference between %LOCALAPPDATA% and %APPDATA% in Windows Vista/7? I was thinking if it's not unreasonable to store Cabal stuff in %APPDATA%, one might as well use that and cover XP, Vista and 7 all in one.

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

Felix Martini

8:44 a.m.

...

Is there any %LOCALAPPDATA% on Windows XP? If not, what is the difference between %LOCALAPPDATA% and %APPDATA% in Windows Vista/7?

XP does not define the %LOCALAPPDATA% environment variable, but it is equivalent to %USERPROFILE%\Local Settings\Application Data. Data in local application data folders remains on one computer and is not stored on a Windows server in a Windows domain setting. Data in application data folders can be transferred over the local network when a user accesses his data on multiple computers. So for larger user data files the local application data folder is often more suitable. Microsoft uses the folder for things like "click once" applications and Google uses it to store Google Chrome so people do not need administrator permission to install it. I run the Haskell platform on XP with the cabal --user config setting on a limited account and i don't have any issues. I think it is better if the platform itself is installed by an administrator account and shared by all users like on Unix. Ideally in a path without any spaces because that prevents a lot of issues when compiling packages that use C bindings. I myself store most software originating from the Unix world in C:\Applications instead of C:\Program Files and the platform folder should preferably be named HaskellPlatform instead of Haskell Platform. Regards, Felix

Regis Saint-Paul

9:18 a.m.

One way in which cabal can be made UAC aware (and therefore request for elevation privileges instead of just failing) would be to embed a manifest in the cabal.exe. This can be done by changing the default manifest (an XML file) that is embedded at link time by GHC. This is supported by GHC through compilation options. It could be used when building cabal for windows. The manifest itself is simple, it just needs one additional line to say it requires admin privileges. All details are here: http://msdn.microsoft.com/en-us/library/bb756929.aspx However, a problem with this approach is that cabal.exe as a whole would be seen as needing administrator privilege, regardless of whether the setting is global or user. If we want to request admin privileges only when actually needed (i.e., when writing in a protected folder). To address this, there are several options: - have two distinct executables for cabal, cabal-global and cabal-user with different manifest - use windows API for requesting elevation during the process (ugly) - use shellexecute command for running a process performing just the task that needs elevated privileges. Someone mentioned the "runas" command. But unlike su on linux, runas only changes the user, not the privileges attached to it. That is, on VISTA and 7, even admin users are seen as "standard user" unless they explicitly acknowledge they want to elevate a process with admin rights. So if you need admin rights while running as admin, you are only prompted for yes or no, while if you need admin rights as a non-admin user, you are also prompted for admin pass. This was done do address the legacy problem that everyone was using windows as admin in the first place. Also, the AppData folder is for application data, not for the application itself. I'm not sure how far one needs to go in terms of well-behaving for windows when it comes to multi-platform applications. I'd like to point out the "Application Compatibility Toolkit" which allows testing if an application is well behaved for vista and 7 and provides guidelines for that (it's a free download): http://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b581-47b0- b45e-492dd6da2971&DisplayLang=en you may also need to download the application verifier here: http://www.microsoft.com/downloads/details.aspx?FamilyID=c4a25ab9-649d-4a1b- b4a7-c9d8b095df18&DisplayLang=en You can use also on XP to test for vista and 7. I tried running it with cabal install somepackage and it points out a number of privilege errors. Note that if cabal was writing packages in AppData instead of "program files", then the problem would only surface when cabal install moves executable in the bin directory. It seems to me that the cygwin/mingw and, more generally, the GNU way of dealing with windows is to mainly ignore the directory structure of windows and install things in a separate directory chosen by the user (possibly in program files or elsewhere), requesting the user to manually change the path accordingly. That could be a solution to consider too. Hope this helps a bit, Regis

Matthijs Kooijman

9:24 a.m.

Hi Regis,

...

- use windows API for requesting elevation during the process (ugly) Why is this ugly? This seems like an elegant solution, to get privileges only when you actually need them?

Gr. Matthijs

Bulat Ziganshin

9:36 a.m.

New subject: Re[2]: Cabal install on Windows 7

Hello Matthijs, Thursday, September 10, 2009, 5:24:57 PM, you wrote:

...

...
- use windows API for requesting elevation during the process (ugly) Why is this ugly? This seems like an elegant solution, to get privileges only when you actually need them?

afaik you need to run special COM server with elevated privileges. it's much easier just to run external app with proper manifest see page 22 in http://pascalfonteneau.developpez.com/articles/delphi/vista/uac/VistaUACandD... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Regis Saint-Paul

9:46 a.m.

I'm not familiar with cabal source code enough to actually assess how much of a problem it would be but I assumed so because: - one would need to identify the exact location in the cabal code where elevation will be required. That means one would have to check if a folder where cabal wishes to write is or not protected. For users who install outside of program files (under msys for instance), failing to do so would raise unnecessary UAC elevation requests - this would create a less portable code overall (I do not know the extent of windows/linux specific code in cabal code base, but it seems to be very small at this stage). By comparison, the manifest option only requires modifying the build process, leaving the code unaffected. On the other hand, this solution is clearly the best if the objective is to become fully compliant with windows recommendations. To have a nice UAC warning, it would also take to create a signed certificate, etc...(or we just get something like "An unidentified program wants to access your computer" instead of the "windows needs your permission to continue". And probably other side issues to consider. So you are right, "ugly" is not appropriate. It just builds down to more work and more platform specific code. Cheers, Regis

...

-----Original Message----- From: Matthijs Kooijman [mailto:matthijs@stdin.nl] Sent: Thursday, 10 September 2009 3:25 PM To: Regis Saint-Paul Cc: haskell-cafe@haskell.org; 'Duncan Coutts' Subject: Re: [Haskell-cafe] Cabal install on Windows 7

Hi Regis,

...
- use windows API for requesting elevation during the process (ugly) Why is this ugly? This seems like an elegant solution, to get privileges only when you actually need them?

Gr.

Matthijs

Regis Saint-Paul

10:05 a.m.

One last note as it may be confusing in previous message...I mention to use windows API, but there is no API per-se that can elevate a process already running. It takes to create another process which, at startup time, will popup the elevation dialog. The win32 function to call is therefore just the shellexecute(). --Regis

Bulat Ziganshin

10:19 a.m.

New subject: Re[2]: Cabal install on Windows 7

Hello Regis, Thursday, September 10, 2009, 6:05:19 PM, you wrote:

...

One last note as it may be confusing in previous message...I mention to use windows API, but there is no API per-se that can elevate a process already running. It takes to create another process which, at startup time, will popup the elevation dialog.

to be exact, this process should manifest itself as requiring Admin privileges and Windows itself will popup dialog asking user whether he trust this executable -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Duncan Coutts

14 Sep 14 Sep

2:38 p.m.

On Thu, 2009-09-10 at 15:18 +0200, Regis Saint-Paul wrote:

...

One way in which cabal can be made UAC aware (and therefore request for elevation privileges instead of just failing) would be to embed a manifest in the cabal.exe. This can be done by changing the default manifest (an XML file) that is embedded at link time by GHC.

...

However, a problem with this approach is that cabal.exe as a whole would be seen as needing administrator privilege, regardless of whether the setting is global or user. If we want to request admin privileges only when actually needed (i.e., when writing in a protected folder). To address this, there are several options: - have two distinct executables for cabal, cabal-global and cabal-user with different manifest - 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.

...

Also, the AppData folder is for application data, not for the application itself. I'm not sure how far one needs to go in terms of well-behaving for windows when it comes to multi-platform applications. I'd like to point out the "Application Compatibility Toolkit" which allows testing if an application is well behaved for vista and 7 and provides guidelines for that (it's a free download):

...

You can use also on XP to test for vista and 7. I tried running it with cabal install somepackage and it points out a number of privilege errors.

Thanks for that.

...

Note that if cabal was writing packages in AppData instead of "program files", then the problem would only surface when cabal install moves executable in the bin directory.

It seems to me that the cygwin/mingw and, more generally, the GNU way of dealing with windows is to mainly ignore the directory structure of windows and install things in a separate directory chosen by the user (possibly in program files or elsewhere), requesting the user to manually change the path accordingly. That could be a solution to consider too.

Our aim is really to do things the proper way on each platform. We follow FSH/autoconf conventions on Unix and we aim to do the right thing on Windows and OSX. The main issue is that there's not many of us who are familiar with what the "right thing" is on the other platforms. Duncan

Regis Saint-Paul

15 Sep 15 Sep

4:14 a.m.

...

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

Peter Verswyvelen

5:24 a.m.

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

Bulat Ziganshin

5:49 a.m.

New subject: Re[2]: 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

Peter Verswyvelen

8:29 a.m.

New subject: Re[2]: Cabal install on Windows 7

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

5726

Age (days ago)

5733

Last active (days ago)

List overview

Download

27 comments

10 participants

participants (10)

Bulat Ziganshin
Deniz Dogan
Duncan Coutts
Felix Martini
Jeff Wheeler
John Van Enk
Matthijs Kooijman
Peter Verswyvelen
Regis Saint-Paul
Sebastian Sylvan