Henry: >> Sections 3.1, 3.4, 4.1, and 4.4 all discuss that Gkrellm supports >> plugins, but there is no information about plugins in the exported >> interface table. How can it support a plugin framework without >> exporting any related interfaces? > Sure, it export /usr/include/gkrellm2/gkrellm.h, in which the structure > GkrellmMonitor is listed, it's used to record all plugin relative > functions. I will add it to export interface of the proposal.
After I've written a plugin, how do I integrate it into the GKrellM infrastructure. Do plugins have to be installed in a particular location, for example, for them to be loaded by the GKrellM daemon? If so, this plugin directory (or whatever interface is used) should be highlighted in the ARC materials and the manpage. >>> 4.11. Security Impact: >>> >>> There is no additional security impact for Solaris. >> How can something which uses OpenSSL, has a plugin framework, and allows >> remote observation of a network's health have no security impact? > I think there is some general security problem when an application > connect to network, it may exist all applications using OpenSSL/plugin. > I will add some words to identify that this application is using > OpenSSL, and support plugin to transfer system status information. Is it possible for a person to write a plugin that does something malicious? What protects the system from malicious plugins? Can only the sysadmin install new plugins, for example? What protects the traffic between the remote and local machine from malicious snooping? I'd guess OpenSSL is being used for this. I'm just saying that the answer should be more fleshed out. "None" isn't a good answer in this case. -- Brian
