Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support shared/read only install of a product #34

Open
laeubi opened this issue Oct 23, 2023 · 1 comment
Open

Support shared/read only install of a product #34

laeubi opened this issue Oct 23, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@laeubi
Copy link
Contributor

laeubi commented Oct 23, 2023

When I launch the installer I'm currently presented with this standard options:

grafik

as part of the Eclipse WG imitative to supporting secured installation layouts for eclipse, it was decided that the most safe way seems to install eclipse in a read-only way so probably only elevated administration user can modify the original install of eclipse (especially placing new file in the root of eclipse what might be a source of DLL Injection or replacing the eclipse.exe and similar treats.

Oompf should therefore help the user to make things more secured by the following ways

  1. If installed a product it should make sure that the folder and its files are only writable by that user for example using NIO Path API if that is not possible we might want to warn the user about this insecurity
  2. There might be an option to make the install even readonly for this purpose the product has to be started once with -initialize and then can be made readonly as described here. Even though eclipse chooses a default of <user-home-dir>/.eclipse/<product-id>_<product-version>/configuration for the private user part, this might be configurable as well for the convenience of the user.
  3. There might even be an option to create a shared install the main difference is that the product will not installed with user-right but elevated rights that make the install read only and even not modifiable by the current user account. This is the most complex because it will require integration with the native operation system way of requesting elevated permissions but thanks to FFM API even that would be solvable from java

Option 1+2 seem quite straight forward, but still have one flaw: If my user account get compromised even for a short time (e.g. forget to logout while taking a coffee) my eclipse might get compromised even though of course this opens up for much more serve security problems. Option 3 is the most complex but what one today might expect from modern installers, especially in managed environments.

I have used shared-installs (manually configured of course) in the past for supporting Windows-Terminal Server, so even beside the security aspect supporting shared-installs would be great for the users (or more their admins).

@merks
Copy link
Contributor

merks commented Oct 23, 2023

Some of concerns are covered by documentation here:

https://www.eclipse.org/setups/installer/question/

E.g., one can avoid using a bundle pool or one can create shared installations even with a bundle pool running as an admin and managing the location of the bundle pool.

@merks merks added the enhancement New feature or request label Feb 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants