We rely on the include path to find many of these headers. It
especially doesn't make sense to use #include "foo.h" for headers
in the top-level include directory.
The format value has to be a string literal, every time.
Otherwise, you are not using these functions correctly. To reinforce this fact, I putrestrict over every non-contrib example of this I could find.
Starting with Python 3.11, backtraces may contain a line with '^'
characters to bring attention to the important part of the line.
Also replace "REJECT" with "0" in backtrace output for Python 3.11.
Previously we needed to include headers required by the various
sudo*h files. Now those files are more self-sufficient and we
should only include headers needed by code in the various .c files.
The Signals enum was added in Python 3.5. If it is not present we
need to iterate over the dictionary items, looking for signal name
to number mappings. Fixes the signal tests with Python 3.4.
When converting sudo options from a dictionary to a tuple we need
to track the current index into the tuple separately from the
position of the dictionary entry.
Dictionary order is not stable in Python < 3.6 so we need to sort
by key to have consistent results.
The LogHandler output is also different on older Python versions.
Also, don't stop running python tests after the first error.
If "ClassName" is not specified, load the one and only sudo.Plugin from
the module (if so), otherwise display which plugins are available from
which the system admin can choose.
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.
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.