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.
This used to indicate that email had been sent to the administrator
telling them that someone tried to run sudo. Whether or not sudo
sends email is now configurable, so the warning may not be accurate.
It is also confusing to the user since they will not know who the
incident is being reported to. See also https://xkcd.com/838/
For "sudo -n" we only want to reject a command if user input is
actually required. In the case of PAM at least, we may not need
to interact with the user. Bug #956, GitHub issue #83
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.
init_eventlog_config() is called immediately after initializing the
Defaults settings, which is before struct sudo_user is setup. This
adds a call to eventlog_set_mailuid() if NO_ROOT_MAILER is defined
after the invoking user is determined. Reported by Roman Fiedler.
