If the user is not allowed to run a command, we try to give them a
more useful message than "Sorry, user foo may not run sudo on bar."
However, this should only be done when running, not listing, a
command. Otherwise, it would be possible for a user with no sudo
privileges to use "sudo -l /path/to/some/command" to determine
whether an executable exists in a directory that they do not have
search access to.
This avoids sending mail for users running "sudo -nv" or "sudo -nl"
even when mail_badpass or mail_always are enabled. We already avoid
logging in that case but mailing was not disabled when that change
was made. Bug #1072.
The change to always get the current time when building a struct
evlog in sudoers broke the data and time written for exit records.
This only affected file-based logs, not syslog. GitHub issue #405.
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.
