Community
Participate
Working Groups
I've originally hit this in bug 322344. Ian told me that updates don't work in shared install scenarios. Shared install scenarios are going to be way more popular than ever before, thanks to Windows investing in it's security and UAC. Typically when installing an appliction on Windows (vista/7) in Program Files, special privileges are required. In most installers (e.g. MSI) this is done via privileges elevation. So one part of application runs with current user privileges and other part with system user privileges. This requires almost no effort from the user. P2 should also be able to run in elevated privileges. This is specially required for update operation in shared install.
I personally thing this should be more inclusive than just Windows 7. The ability to support elevated privileges when installing (possibly through username / password authentication) seems like a good feature in general.
yea, other OSes support would be great too. The windows+update scenario seems just most urgent. Anyway, on Windows the only way to elevate privileges is to start another process with "runAs" verb, because existing process cannot increase it's privileges. So supporting elevated privs would be probably as difficult as: 1. separating out provisioning operation to entirely separate process. An easy way would be to invoke p2.director-like app from p2 UI. But they'd still need to communicate somehow (e.g. for progress feedback, finish notification etc.) 2. starting the new process with "runAs" verb. This "verb" thing is an extra attribute that .Net programmers can use in shellExecuteEx. I'm not sure if there's such thing in Java.
...ah and last thing is to add a little UAC shield on the "Update" button to emotionally prepare user :-) (see it e.g. here: http://www.devzest.com/blog/post/Programming-Elevated-PrivilegeUAC.aspx)
I totally agree that this becomes a must on windows where ppl are not completely used to the fact that their application is "locked". For linux and mac, though this would be interesting, I think users are more accustomed to having to switch to another user or run sudo to change their system, as such it is not as critical / important. Jacek, would you have some cycles to provide a little dll and jni that respond to 2 calls, one to check if the user is the super user, and another to execute a command line as super user? Even if this would not allow to report proper progress in the original process, at least this would give us the ability to experiment with the functionality.
Pascal, I'm off for next two weeks for vacation, but after that sure. For now, I saw an easy way to elevate privs from SWT at http://www.milewski.ws/2009/04/using-vistas-uac-in-swt/ Blog author appears to be SWT Nebula committer :-) Lukasz, would you like to contribute this great piece of code from your blog on EPL terms? thanks
Something like this probably belongs in the launcher. One possibility is a "restart with elevated privileges" for Eclipse itself instead of p2 spawning a new elevated process. Someone could raise a bug on the framework if this seems like the way to go. One thing is that the launcher currently uses CreateProcess to do the restart, it seems that you can't elevate that way and the restart code would need to change to use ShellExecute instead. Also, if this is in the launcher, we would probably have to investigate equivalents on all the other platforms.
(In reply to comment #6) > Something like this probably belongs in the launcher. One possibility is a > "restart with elevated privileges" for Eclipse itself instead of p2 spawning a > new elevated process. Someone could raise a bug on the framework if this seems > like the way to go. > > One thing is that the launcher currently uses CreateProcess to do the restart, > it seems that you can't elevate that way and the restart code would need to > change to use ShellExecute instead. Also, if this is in the launcher, we would > probably have to investigate equivalents on all the other platforms. Andrew, what do you think of the idea of a 'privileged engine'. The idea would be to create the provisioning plan using the all the normal p2 API, but then execute the plan as a different process, presumably with elevated privileges. If we created this 'privileged engine' as an IApplication, it might just be a matter of using the launcher to start another process. The challenges I see would be: 1. How do run something at a different privilege level (or under a different user). 2. How do you communicate to the engine what the plan is 3. How do you communicate progress back to the calling program 2 and 3 could probably be dome with some sort of IPC using ECF.
>Something like this probably belongs in the launcher. One possibility is a "restart with elevated privileges" for Eclipse itself Running a complete instance of eclipse in elevated mode somewhat makes me worried that we could be a vehicle through which people chose to attack. In fact, just running the p2 plugins could result in the same situation, but the smaller the window of opportunity the better it is.
> About adding the code in the launcher What advantage does this offer us over putting it in a separate jar? As for the support on multi platforms, this is not something that I'm extremely worried about because currently this is only an issue for Windows users, as linux users are already used to this sort of separation of user vs super-user. The other thing is that for Linux, there exists probably a different way to open a dialog as there is variant of linux... :(
Restarting whole Eclipse in privileged mode may cause lot more trouble. E.g. in privileged mode Eclipse will use eclipse/configuration, whereas in non-privileged mode, Eclipse has no write access global configuration and uses $HOME/configuration. As a result user may end up in different workspace, with different settings, etc. and he just wanted to make p2 update :-)
Any news on this? It's hugely important. I just tried to install SR1 updates on Win7 and received the "conflicting dependency" message. I had no idea what the cause was at first.
Adding Dean to the CC as he expressed interest in investigating this during one of our Equinox calls.
*** Bug 297932 has been marked as a duplicate of this bug. ***
From the Monday p2 call it was decided that there are two issues: 1) Improve the behaviour (error message) that occurs when the Eclipse base in installed in the Program Files directory and can not be upgraded by a "regular" user. 2) Consider prompting a user for an admin password and elevating the privilages for the purposes of updating. It was agreed that step 1 should be tackled first and step 2 be reconsidered later as there are issues with complexity and resource availability for the work. Step 1 will be of benefit for all platforms and even if we end up supporting automatic user elevation.
When checking for updates with a read only shared base install we should display upgrades that require a base upgrade in a disabled state with some hint that the user should log in in as administrator to upgrade the base first. This is preferable to hiding the update altogether since we should give the end user the information they need to pester their help desk to get the base installs updated if they find upgrades they need.
There are two scenarios being considered in the Check Update UI. Scenario 1: Some local bundles need updating and some shared bundles need updating. The local bundles have no requirements on the shared bundles. I am close to releasing a patch for this scenario. The patch will: a) Display the shared bundles with the disabled IU icon (black and white). The shared bundle will be unchecked in the UI. b) The local bundles will display with regular IU icon and will be checked. c) The next button will be enabled and no errors will be reported in the Wizard. Clicking Next through to Finish will result in the local bundles being updated. d) Attempting to check mark the shared bundles will not place a check mark in the box, will select the IU in the list so that the details area will display a message about the IU. The regular IU description will be prepended with the message: "You do not have sufficient access privilege to update this bundle. Please contact your system administrator" The current, unpatched update UI computes a plan for updating all IUs before the wizard is opened. To achieve the described behaviour the patch must recompute the plan if the first computation is found to have errors. Is this acceptable? The other alternative is to remove locked IUs from the initial proposal before the plan is first computed. However, such a strategy means that we can not display shared IUs in a disabled state so the user would not know that there are in fact available updates that a root user could install for them. Scenario 2: A local bundle needs updating and requires a shared bundle that also needs updating. This scenario is more complicated and I have no solution for it at this time. I believe we would need changes in the way lock status is communicated to SAT4J or other changes in the planner. The current error returned by the planner is that bundle A v1.0.0 and bundle A v1.0.1 can not exist together. There is no mention that the "real" problem is that v1.0.0 can not be uninstalled because it is locked. The strategy used for Scenario 1 can not work since we do not have the dependency tree. The private bundle is not locked but a required bundle is. If people are happy with the behaviour described for the Scenario A patch I will release it today or Monday. If people have suggestions about solving Scenario 2 I'd love to talk to you.
Created attachment 190429 [details] Patch for Scenario 1 Added patch to solve Scenario 1 using the 2nd calculate plan if the 1st has an error
Created attachment 191556 [details] Updated patch for scenario 1
Patch for scenario 1 released. Are there any suggestions for scenario 2?
Created bug 343768 for remaining open issue scenario 2 referred to in comment 16. Closing.
