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

Reply via email to