plugins: installation, documentation?

[jqj]

Context: OJS 2.3.3-3 on Linux/mysql. Multiple journal configuration.

As I was developing a locally needed plugin, I noticed that the documentation for plugin security is unclear. I'm assuming that the plugins directory in OJS should not be writable by the httpd user (normally apache). Is that correct? This seems obvious, except that the OJS interface (Journal Manager / System Plugins) provides an "Install A New Plugin" link that only works if the plugins directory is writeable. Assuming that "Install A New Plugin" in the web interface should not be available to mere journal managers, what's the preferred way to manage plugin installations requested by particular journals?

Also while working on this plugin I realized that I don't know where to find information in the documentation. I'm aware of the users guide and technical reference manual. An example of a question for which I didn't find an obvious answer:
What is the intended semantics (on block plugins) of block context values as returned by the getSupportedContexts() method? In particular, what is BLOCK_CONTEXT_HOMEPAGE supposed to do (show/hide block on the journal homepage?), and why do so many block plugins specify BLOCK_CONTEXT_RIGHT_SIDEBAR but not BLOCK_CONTEXT_LEFT_SIDEBAR?

One can of course read the code in lib/pkp/classes and classes, and sometimes the comments are helpful. But it is sometimes difficult to understand whether the observed code represents intended behavior or a bug.

[asmecher]

Hi JQ,

We've not had the chance to update the technical reference for a while, so it's missing detail on a few things that have been refined over the last few releases. Hopefully we'll get the chance soon; in the meantime, I'm happy to document some of this here in the forum.

Many of the built-in plugins have a fixed behavior for copies of OJS that haven't yet been installed and thus don't have a plugin settings storage facility yet in the DB -- that's why you see getBlockContext() returning BLOCK_CONTEXT_RIGHT_SIDEBAR in a conditional in e.g. plugins/blocks/help/HelpBlockPlugin.inc.php. That code is only effective if the system isn't yet installed. Once the system is installed, many plugins have default settings installed from XML files; again, for the Help block plugin, see plugins/blocks/help/settings.xml. Those are installed into the database when you create a journal and can be modified in Journal Setup page 5.

The BLOCK_CONTEXT_HOMEPAGE was introduced by one of our developers a while ago with the idea of adding block-style content to the homepage, but none of the blocks that ship with it currently use that context. (There might be something in the Plugin Gallery that uses this; if you're interested, I can ask.)

As for plugin permissions -- there are two ways of installing a plugin. First, via the web interface, which does require that the web server account (e.g. www-data or apache) be able to write to the plugins directory. I don't consider that to be an ideally secure setup, among other reasons because it means that the server can be compromised if you lose control of a Journal Manager's account, i.e. if a password gets stolen. You can improve upon that by either setting the permissions just before installing a plugin, then revoking the extra privileges afterwards, or by using a command-line install process. To do that, unpack the plugin into the appropriate directory (e.g. plugins/generic for a Generic category plugin), then run "tools/install.php install" to register the plugin with the system.

Regards,
Alec Smecher
Public Knowledge Project Team

[jqj]

Thanks Alec.

I think I have to argue that it's not really acceptable to require that journal managers be trustworthy on a multiple-journal system. Particularly if you are hosting journals run by other organizations, you have to give people in those organizations JM roles for their own journals (since they have to do the work), but you don't want to risk a naive user accidentally deleting an important plugin rather than disabling it, or uploading arbitrary PHP code that could, for instance, accidentally destroy data (the archives of the scholarly record embodied in journal articles are precious, and backup normally doesn't happen instantaneously) or intentionally sniff the root password. Malicious isn't likely, but accidental seems too probable.

It's not problematic to allow random JMs to en/disable a plugin or update the settings for plugins in their own journals, but I do think it's very bad to allow them to upload, update, or delete plugins. And I don't want to mislead them into thinking its possible so just setting file protections isn't enough -- if the recommended configuration were to protect the OJS installation so these links didn't work, then it would be better not to display the links.

On the other hand, I can see that on a small site with a single journal you really would want to give the JM this capability (though why not just tell that person the root password?).

What OJS may need is a new system-level role of "site administrator" that would provide access to many of the same capabilities that the root user currently has, analogous to giving someone sudo rights on Unix. This would include access to the site menu or a subset of it, and would be required for access to any current journal manager commands that have the capability of creating a security problem for the whole site.

Absent that change, I think the installation documentation would do well to be clarified about required permissions given various security models, and the documentation of the journal manager role needs to be updated to clarify that it should only be given to someone who is trusted with administering the whole site.

On HOMEPAGE, thanks for the clarification. That was what I had concluded from reading the code, but given that it hadn't been implemented I had wondered if maybe "HOMEPAGE" was intended for customizing a journal homepage rather than the site homepage.

[cnelson]

Hi Alec,

I agree with what's been suggested here by jqj, and would like to add another thought. I'm generally comfortable using a command-line interface and tried that first to install a new block plugin we have developed, but the install process seemed to want me to install OJS from the very beginning! Perhaps I was doing it wrong, but I ended up canceling the program because I see no need to reinstall from scratch (and have to reinput all the install settings for the system) just to install one block plugin. Is there no better way to install a plugin from the command line?

On the other hand, when I went to install the plugin from the web interface, it was smooth fast and easy. We are running a multi-journal instance of OJS and I too hesitate to have all of our various journal managers have this power, but the web install was vastly simpler than the command line install, so I'm going to do it that way from now on and just hope that the honor system holds and no one else will do the same.

Given that plugins are site-wide, it makes sense to only have the system admin be the one to be able to install them - even in a one-journal instance, presumably the system admin and the journal manager are the same person, so that shouldn't be a conflict.

CNelson

[asmecher]

Hi CNelson,

Thanks for the feedback; we're working with a lot of new structures as part of the OMP project, and have been thinking along the same lines. Eventually those ideas will filter back into OJS and OCS.

It's possible to install plugins from the command line -- place the code in the right directory, then run "tools/upgrade.php upgrade" to register the plugin with the system. (If you haven't done this before, I'd suggest dumping your database beforehand just in case you run into something unusual like an incomplete upgrade.)

Regards,
Alec Smecher
Public Knowledge Project Team

[cnelson]

Hi Alec, Thanks! I'll give it a try and ask more questions if we tun into any issues.

CNelson