As of sudo 1.9.1 the sudoers file is opened by the audit plugin,
not the policy plugin. As a result, plugin options set for
sudoers_policy have no effect. If sudoers_policy has plugin options
in sudo.conf and sudoers_audit is not listed, move the options to
sudoers_audit so they will have an effect.
This setting is an argument to the sudoers plugin, similar to how
sudoers_file, sudoers_mode, sudoers_uid, etc. are implemented.
The default value is true.
Now that logging of successful commands is performed by sudoers as an
audit plugin we need to load sudoers_audit if sudoers_policy is also
loaded. Otherwise, accpted commands will not be logged.
With this change, the sudo front-end will send an "accept" audit
event to the audit plugins after all the I/O logging plugins have
been initialized. This can be used by an audit plugin that does
not care about the result of the individual policy and approval
plugins and only wants to receive a single "accept" event if all
policy and approval plugins have succeeded. The plugin_type argument
for events sent by the front-end is SUDO_FRONT_END (0).
These are less confusing than #include and #includedir when the
hash character is also the comment character.
This commit also adds real parsing of include directives as opposed
to the pure lexer approach used previously. As a result, it is now
possible to include files with spaces by either using a double-quoted
string or escaping the space characters with a backslash.
By default, sudoreplay will exit when it reaches the end of the
timing file. With the -F option, it will keep going until the
timing file is finished and its write bit is cleared.
We want the log server to work with the default configuration. If
the default certificate path exists, it will be used with the default
listener. If the user explicitly enabled a TLS listener we always
attempt to use it. If TLS was specified but no cert file was set,
the default location will be used (and an error will occur if the
cert cannot be loaded).
Previously, if multiple instances of the same command line option were
specified, the last one would be used. This meant that, for example,
"sudo -u someuser -u otheruser id" would run the command as "otheruser".
This has the potential to cause problems for programs that run sudo with
a user-specified command that do not use the "--" option to indicate
that no more options should be processed. While this is a bug in
the calling program, there is little downside to erroring out when
multiple options of the same type are specified on the command line.
Bug #924
This makes it easier to detect a plaintext client sending to a
TLS port. Without this, the TLS server will be silent as it
waits for the client to initiate the TLS connection.
For TLS connections we now do the TLS handshake immediately before
the ServerHello message. This lets the client recieve an alert
from the server is there is a handshake error after the TLS connect
has succeeded. It also means that the contents of the ServerHello
are protected from a man-in-the-middle attack.
We have to limit the length of SUDO_COMMAND to avoid getting E2BIG
from execve(2) for very long argument vectors.
The command's environment also counts against the ARG_MAX limit.
Debian bug #596631
