Tests did not catch the issue where errstr was not set correctly, but
its pointer contained the expected data, because the memory allocator
reused the same space for storing the string.
Now it is either verified to be NULL, or reset to NULL.
The error is always stored in plugin_ctx, but it is only set into errstr
if the API version is enough. (Previously it worked the opposite:
we only stored the error if API level was enough.)
Plugins can raise a sudo.PluginError exception to add context message
for the failure.
The callback's errstr gets filled up with the specified message.
But, as sudo expects a string constant (will not free the string),
we store it in the plugin context at least until next callback
invocation.
Unfortunately the test did not catch this mistake, because it only
searches that "Python policy plugin API version" string is present
and does not check the version.
It is a bit more code, but it is more "pythonic" and easier to debug
as the enum values also know their names.
It is also an API break, eg. sudo.RC_OK becomes sudo.RC.OK as sudo.RC will
be the "type" of the enum, but I guess that is acceptable before the
initial release.
The main problem was that string array objects were constructed
differently:
- if constructed by the test, then the elements were constant
- if constructed by the plugin, then the elements were allocated
Modified it so that now each array contains allocated strings so
they can be handled similarly. For freeing, I have used the
str_array_free function from the plugin, so I have linked its object
into the test runner.
Happy path is now free of "definitely lost" memleaks, so the test
can be used for valgrind.
PyArg_ParseTuple sets the py_config_tuple pointer, but it does not
increment the reference count, so by decrementing, we end up freeing
the argument passed in.
On each plugin initialization we create a separate python interpreter
which gets stored in the plugin_ctx. The main interpreter is
stored in py_ctx and is used for creating more interpreters (if more plugins
get loaded) and final python deinitialization.
The "traceback" module import and the ImportBlocker initialization was
moved, because it has to happen inside the plugin specific interpreters.
Adapted the default sudo_printf from sudoers plugin to be able to print
errors before plugin open() gets called. (This is used by the multiple io
plugin loading to display error for too much plugin load.)
Since this makes us always have a sudo_log, I have removed the logic about
whether it is available or not.
Separate sudo io plugin symbols are created which stores wrapper
functions adding the context of which python plugin the callback is
about.
These sudo io plugin "slots" get generated with macros by the preprocessor.
This makes sudo support loading multiple python IO plugins like this:
(note the differences in the symbol names)
Plugin python_io python_plugin.so ModulePath=... ClassName=SudoIOPlugin1
Plugin python_io1 python_plugin.so ModulePath=... ClassName=SudoIOPlugin2
Plugin python_io2 python_plugin.so ModulePath=... ClassName=SudoIOPlugin3
They are platform dependant, so their test would fail on some platforms.
While we could create separate plugin for the tests, I like the idea that
the examples are ensured to be working.
I believe this is a good compromise for being able to auto update the
test cases.
When calling validate() python function, TypeError exception was thrown
("argument list must be a tuple"), because the call does not have
arguments, and python does not accept empty tuple for execution. NULL
must be used instead, which was handled as argument construction failure
previously.
Storing them as "tuple" instead of "set", so they have a fix order.
This makes the output of the list() example stable. ("set" is printed out
in random order)
IO/Group/Policy Python API version is displayed instead of sudo version,
because that is not very meaningful in this context.
They are only displayed in verbose mode.
Example plugins express it more concrete that they are displaying their
version, not the API version.
