Secure Preferences management improvement

[arnaudf-iter]

We are facing a dilemma with the secure preferences as we want:

1. To install a default encrypted file with all the passwords for css, alarm server and archive engine (under /opt/…)
2. This file need to be read-only, as if the user enters a wrong password, it would be saved and he/she won’t be able to restore the good default one as it was overwritten (restore button from the GUI preferences)
3. But for some usage, we need to modify the default CSS settings when we work for example in production (passwords could be different from development) in order to plot data from different location and rdb user/password. So we would like to change them using the GUI and when the exception is raised because the encrypted file id read-only, choose to store the new encrypted file under the workspace instead of the install location.

Proposed solution:

Add a new preference to org.csstudio.security:

# Define if the location where the encrypted settings are stored defined by 
# 'secure_preference_location' preference is read only or can be overwritten
#
# false = default behavior, the encrypted settings can be overwritten
#
# true = the encrypted settings are loaded from the 'secure_preference_location'
# but are written in a secure store located within the workspace. 
# The encrypted settings are restored/reloaded from 'secure_preference_location'
secure_read_only=false

Update

core/plugins/org.csstudio.security.ui/src/org/csstudio/security/ui/PasswordFieldEditor.java

and

core/plugins/org.csstudio.security/src/org/csstudio/security/preferences/SecurePreferences.java

to handle this new behavior without impacting the old one (preference will be set to false by default)

Are you OK with this change ?

[kasemir]

Sounds good.

[kasemir]

A little late now, but if you are looking at 'common' settings vs. per-user settings, have you checked the basic Eclipse support for multi-user installs, making the 'configuration' directory read-only etc.? See http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/multi_user_installs.html

With the secure preference support, we never followed the basic Eclipse approach, which is:
Cannot write/update settings in the install location -> Write to user's workspace (instance location).
With your new secure_read_only=false, you are actually doing just that, but then not using the workspace/secure_settings.
Maybe it should always try to write to secure_preference_location, and if that's read-only, write to workspace/secure_settings. So it'll be like Eclipse settings in general.
By default, it would use workspace/secure_settings over secure_preference_location, but with secure_read_only=true, it would ignore workspace/secure_settings.

[utzeln]

Thanks. As you said too late for our release mid-June but we will look at it for the next one.

[utzeln]

We plan to work on this issue again. So let's resume what remains to be done.

We want to store the passwords in Eclipse install location:
org.csstudio.security/secure_preference_location=Install

When we change the default password in CSS GUI or headless CSS products with the option -set_password, this fails because the install location is read-only. In this case, instead of storing the updated secure_store.dat in the workspace under .metadata/.plugins/, we could use workspace/secure_settings.

If we agree on that, then we do not need the specific preference secure_read_only=true. Right?

[kasemir]

For SNS, I do want to store passwords in the install location, not the
workspace, because they should be global, entered once and then apply to
every user. When I install CSS, I once enter the password in the GUI or via
-set_password.

You had the suggestion to somehow handle the read-only case.
For me, just failing would be OK. If I cannot set the password during the
initial install, I'd like to know.
My users should not change the password, so if it fails because of a
read-only install location, that's fine. If a power user really needs to
change it, they can use their own -pluginCustomization with secure_
preference_location=instance.
Silently writing to a non-install location when I specifically asked for
secure_preference_location=Install could lead to a lot of wasted time
wondering what's happening.

On Thu, Sep 18, 2014 at 8:42 AM, utzeln notifications@github.com wrote:

We plan to work on this issue again. So let's resume what remains to be
done.

We want to store the passwords in Eclipse install location:
org.csstudio.security/secure_preference_location=Install

When we change the default password in CSS GUI or headless CSS products
with the option -set_password, this fails because the install location is
read-only. In this case, instead of storing the updated secure_store.dat in
the workspace under .metadata/.plugins/, we could use
workspace/secure_settings.

If we agree on that, then we do not need the specific preference
secure_read_only=true. Right?

—
Reply to this email directly or view it on GitHub
#532 (comment)
.