This only happens when sudo unloads the last python plugin.
The reason doing so is because there are some python modules which
does not support importing them again after destroying the interpreter
which has imported them previously.
Another solution would be to just leak the interpreters (let the kernel
free up), but then there might be some python resources like open files
would not get cleaned up correctly if the plugin is badly written.
Tests are meant to test the scenario sudo does, so I have modified them
to generally do not unlink but only a few times (~per plugin type) so it
does not use 48 interpreters (one gets started on every plugin->open) and
it is visible at least which type of plugin fails deinit if there is an
error.
The python_plugin_api_rc_call function already decrements the
refcount of py_args.
Python avoids the double free, but the error gets shown if using python
debug build.
even if the arguments are not used (eg. when there is no "close" call
in the plugin).
It was not really a memleak, because interpreter is deinitialized anyway,
which frees the object.
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.)
We need a close function to be able to to free memory allocated for
errstr. Unlike the other plugins, the close function is called
immediately after the plugin's check or show_version function.
The plugin does not remain open until the command completes.
The scriptdir contained a path relative to where the target was started.
The scripts are called like "$scriptdir/script_name" which is fine with
relative path as well, until the current directory is not changed.
But things like
cd $srcdir && $scriptdir/script_name
fails (if building in separate build directory).
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.
