pmsec-devel Mailing List for PMVAdmin

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On 4/19/06, Sam Douglas <sam...@gm...> wrote:
>
> Ah, yes. Is there a way around calling these functions? Libraries
> generally _don't_ call functions in the application. What you might want =
to
> consider is a semi-secure way of giving the plugins limited access to
> functions (i.e. "managed" access).
>

A way arround? Ive been trying to think of a way of avoiding it for a while
now but I dont think it would realy be properly possible.

The plugin needs to call functions in the management console to perform the
following actions:

   - Loading its configuration data
   - Saving its configuration data
   - Recieving data from the storage services
   - Sending data to the storage services

The most obvious way to do this to me, is to NOT PASS AROUND OBJECTS
>
> Rather, construct a "table" containing the function's signature, and the
> type of parameters it takes. You would then pass this table to the plugin=
-
> it is all of the external functions it is allowed to call.
>

Yes, I considered this but at this stage I have no experience with such
things. I have seen it done however - WinLogin provides a GINA component
with a table of  functions it can call in winlogon.

This is similar to how Qt handles its signal/slots (connect adds the
> slot/signal signatures to a table (array of data structures) in memory an=
d
> then given the string representing the function name, it looks through th=
e
> table of functions and executes the function pointer.
>
> Table 1: Example table
>
> function_name          function_p        function_args1
> function_args2
> my_function            0x000F0012        char                  int
> die_minions            0x13431421        int                   int
>
> This would be interpreted as the function prototypes:
> my_function (char, int);
> die_minions (int, int);
>
> This would require the plugin to be very up-front about which functions i=
t
> wanted access to - i.e. when it was initialised, it returned a list of th=
e
> functions it wanted, and then the management console would construct the
> function table accordingly.
>

Probabily not much need for this. At the moment I can only think of about
four functions that would need to be made available to the plugins and most
plugins would make use of them.

That is getting kind of ugly though; the management console would need to
> have an existing list of all of the functions, which would probably requi=
re
> a preprocessor to create at compile time - not nice, but could be quite
> powerful.
>
> Giving the library pointers to the objects should work too; but might tak=
e
> a bit of trying to get rid of all of the cryptic problems. It is also
> dangerous in the sense that every plugin will have the power to corrupt y=
our
> configuration nicely.
>

About the only danger is that a plugin might try to delete the management
console object. It couldnt mess with anything else however. Right now the
only public members of the class are the four mentioned functions, the
constructor and the destructor.

Another (safer) alternative is to not let the library directly access
> management console calls. I cannot really think of where this would need =
to
> happen.
>
> When the list of "objects" in the main window is being populated, it woul=
d
> be better if the MC just called a function in the plugin which returned w=
hat
> it wanted to put into the lists etc.
>

That is what it is currently setup to do. About the only time when a plugin
needs to call functions in the MC is when it is loading and saving data
(either from MCs settings file or from the data access component)

Along with that approach, you would probably need to take a kind of
> "strange" approach to your functions; I suppose you could have them so th=
at
> each call they returned the next element, and then when they were finishe=
d,
> return a null, or a certain error value.
>
> Summary of the three(?) approaches:
>
>    - Table of functions for each plugin; typesafe calling etc.
>    - Passing pointers to certain objects - dangerous. Gives plugins
>    full and unrestricted control over the objects. If a plugin had a bug,=
 it
>    would make it entirely possible to nuke your entire PMVAdmin
>    configuration... not good.
>    - Management console calls functions in the plugin, plugins return
>    what they want.
>
>
> Case "Studies" for each of these approaches
>
> Typesafe calling - Qt's signals and slots
>
> Passing entire objects - probably a lot of proprietary programs out there=
.
> (Free software programmers don't use C++ as much :P )
>
> Program calls library function: most programs written.
>
> A combined approach however, would be to do it like PAM does; where the
> main program initialises the operation, and then the library calls a give=
n
> "conversation" function to talk to the main program. For PMVAdmin, this i=
s
> probably not a very nice method, for the main developers or for plugin
> developers.
>

Currently i have no idea what the errors that MinGW is throwing back at me
mean so I might look into function tables...

--
-David Goodwin
Email: dgs...@gm...

pmsec-devel Mailing List for PMVAdmin

pmsec-devel — PMVAdmin development stuff