We now pass a pointer to the context where necessary. There are a
few cases where we need to request the context from sudoers via
sudoers_get_context() for the plugin API functions. If the plugin
API was able to pass around a closure pointer this would not be
necessary.
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.
The audit plugin already has the correct value for iolog_file, don't
overwrite it with basename(iolog_path). In the future we may wish
to pass in iolog_file and iolog_dir in addition to iolog_path.
Fixes Bug #1046.
If log_input is set, log_{stdin,ttyin} will be set as well.
If log_output is set, log_{stdout,stderr,ttyout} will be set as well.
This provides more fine-grained control over I/O logging and makes it
possible to disable logging piped or redirected intput or output.
This fixes a problem where sub-commands were not being logged to
the remote log server, if configured. Since we don't go through
sudoers_policy_main() again for log_subcmds, we set the flag in
sudoers_audit_accept() instead. The reason this is complicated is
that when I/O logging is enabled the initial accept message gets
sent as part of the remote logging handshake. GitHub issue #174
The hook can be used to log parser errors (sudoers module) or keep
track of which files have an error (visudo).
Previously, we only kept track of a single parse error.
This lets us log based on the command_info[] list passed in from
the front-end. Previously, much of the struct eventlog was constructed
from internal sudoers state instead.
We will need them if there is an error parsing sudoers and leaving
them unset can result in NULL deref. Also set the text domain to
"sudoers" like we do for the policy and I/O logging open functions.
Bug #934.
This is only used when logging events from plugins other than sudoers,
such as an approval plugin. With this change, if an approval
plugin rejects the command the denial will be logged in the
sudoers log file using the message from the approval plugin.
This adds audit plugin support to the sudoers module, currently
only used for accept events. As a result, the sudoers file is now
initially parsed as an audit plugin.
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.
