This means that it is not logged for "sudo -nv" and "sudo -nl".
We only log this message when sudo's -n flag is specified (and not
when the user presses ^C at the password prompt) so that there is
a record of failed non-interactive commands.
We need to track the (monotonic) command start time to be able to
generate an accurate run time. Instead of setting submit time when
the policy initializes (and using that time for logging purposes),
set evlog->submit_time to the current wallclock time when we need
to perform logging. This is more consistent with how sudo logging
was performed in the past. Fixes GitHub issues #327.
Checking for setid commands in intercept mode after command matching
allows us to log a proper error message. Previously, we simply
ignored setid commands when matching and the only indication of why
was in the debug logs.
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.
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.
Reported by the sudo-rs project.
There was a missing space between "list" and the actual command.
This also changes the output to include the command as specified
by the user, not the path found in the path. Previously, if the
command did not exist it would not be included in the message.
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 value of user_args should not contain the command to be run in
"sudo -l command args", only the arguments of the command being checked.
This restores the pre-1.9.13 behavior. GitHub issue #249
Previously there would be one email for the open failure and a
separate one describing the parse error. Now a single email message
contains everything.
privs. Previously, only root or a user with the ability to run any
command as either root or the target user on the current host could
use the -U option. For "sudo -l [-U otheruser] command", NewArgv[0]
is now set to "list" (just like "sudo -l") and the actual command
to be checked starts with NewArgv[1].
Use strlen(), not sizeof(), on "problem parsing sudoers" since it
is a tranlated string and not a constant.
This was caught by the existing overflow checks.
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.
Previously, the warning was displayed when a user was not in the
sudoers file, or was present but not listed for the local host.
The new behavior is to display the warning if a command is denied
and mail is sent to the administrator. Whether or not mail is sent
is controlled by the "mail_*" flags in sudoers. The warning text
is now "This incident has been reported to the administrator." which
is hopefully less confusing. The message will not be printed if
either the "mailto" or "mailerpath" sudoers settings are disabled.
