[kepler-dev] [Bug 5065] New: In shared or administrative installations, the ability to store modules.txt and extra modules locally. This way, the module manager will work smoothly on Windows without having to run as an administrator.

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5065

           Summary: In shared or administrative installations, the ability
                    to store modules.txt and extra modules locally. This
                    way, the module manager will work smoothly on Windows
                    without having to run as an administrator.
           Product: Kepler
           Version: 2.0.0
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: general
        AssignedTo: welker4kepler at gmail.com
        ReportedBy: welker4kepler at gmail.com
         QAContact: kepler-dev at kepler-project.org
            Blocks: 5064
   Estimated Hours: 0.0


(1) In shared or administrative installations, the ability to store modules.txt
and extra modules locally. This way, the module manager will work smoothly on
Windows without having to run as an administrator.

Problem: The file modules.txt is read by Kepler to determine which modules are
active. Both modules.txt and local modules are currently stored in the
installation area, which in shared installations is read-only. Because extra
modules are executed, security might dictate that in shared installation
situations modules.txt not be changed and new modules not be downloaded. This
was the original rationale for going forward with our current design However,
on Windows, the default for installations appears to be to install as an
administrator. As a result, even in private non-shared installations on
Windows, it can be difficult to use the Module Manager. To do so, a user must
remember to run as an administrator, which gives Kepler the ability to write to
the installation area.

Solution 1: Store modules.txt and download new modules not to the installation
area, but to a designated location in the users home where write access will be
available. The downside of this approach is that this would decrease the
security of truly shared installations of Kepler. On the other hand, a problem
with malicious modules may be more theoretical than real at this point, as
modules are now published and retrieved from a centralized source that we
control. Also, if there is a problem with malicious modules, it would affect
not just shared installations, but individual installations; protecting shared
installations does nothing to protect individual installations which are
perhaps just as important. Also, the real risk of malicious modules is low,
given current development patterns.

Solution 2: Try to find a way so that Windows installations are not done by
default on Windows. This may or may not be possible.

Solution 3: Warn users who do not have appropriate write permissions to the
installation area that they may not use the Module Manager. The design of such
a warning should be thought through so that it is non-intrusive and graceful.
For example, it probably should not pop-up at start-up, but only when the user
attempts to invoke Module Manager functionality.

Conclusion: At the very least, users who cannot use the Module Manager due to
lack of permission to write to where Kepler has been installed should be
warned. Perhaps even better, given the prevalence of this problem in Windows
and relatively low security risks, modules.txt and new module downloads should
occur in a local area that is writable.

-- 
Configure bugmail: http://bugzilla.ecoinformatics.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.