[crossfire] Hardening plugin system

Mark Wedel mwedel at sonic.net
Mon Jan 16 01:25:32 CST 2006


Nicolas Weeger wrote:
>>  Presumably for that last point to work, all the functions the change
>> values in the plugin code would need to set some flag.  Otherwise, I
>> don't see how the server can know an object changes.
> 
> Exactly. But remember plugin isn't supposed to access object's fields
> directly but use callbacks which can set such a flag.

  The question is then why not just check for the sanity at that time?

  If its a choice of:

a) when callback to set value is used, we set the value and then mark a flag 
that the object has been modified, and when function is finished, we check 
sanity of object,

or

b) when callback to set value is made, we check the validity

  I'd personally choose b - detecting the error right when it happens is always 
better - it makes it easier to fix the problem.


> True, but for instance in the case of the Python plugin at what point?
> In the Python-C wrappers, ie Python plugin side, in the plugin_common
> code, or in the server-side code? 3rd case is the more foolproof, but
> can be a pain to propagate back (how will the C/Python code know the
> value is invalid? Special integer value for return? Parameter by reference?)

  Depends on the value.

  In your initial post, you mentioned scripts setting the Str value to 50. 
Well, there is a MAX_STAT defined, which the Python-C wrappers could check (or 
plugin common code).

  Some things are certainly harder- not everything has a clear define for 
min/max value.

  but at some level, it can never be 100% foolproof.  The fact the server 
crashes occasionally is proof that even the C code isn't foolproof.  You get the 
complications of some value being valid for one object type, but not another, 
and I don't think there is any real way that can ever be checked (but that same 
problem occurs in maps also - mapmaker could set some value to something invalid)




More information about the crossfire mailing list