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.
Director, Scholarly Communications & Instructional Support
University of Oregon Libraries | Office: 115F Knight Library
1299 University of Oregon | T: 1-541-346-1746; F: -3485
Eugene, OR 97403-1299 | Email: email@example.com