The log message contains user-controlled strings that could include
things like terminal control characters. Space characters in the
command path are now also escaped.
Command line arguments that contain spaces are surrounded with
single quotes and any literal single quote or backslash characters
are escaped with a backslash. This makes it possible to distinguish
multiple command line arguments from a single argument that contains
spaces.
Issue found by Matthieu Barjole and Victor Cutillas of Synacktiv
(https://synacktiv.com).
This removes the need to use the -brtl linker flag which can cause
problems when there are both a .so and .a version of the same library
but with different versions. This was particularly problematic
when using the AIX freeware version of OpenSSL. The --with-aix-soname=svr4
option can be used to build SVR4-style shared libs instead.
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].
If we are logging I/O but not terminal input/output (either because
no terminal is present or because that is what the plugin requested),
the non-pty exec path is now taken.
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.
If sudo_dso_load() fails on a 64-bit system, try to load a 64-bit
native version of the file using system-dependent multilib rules.
If we don't support multilib on the platform, check for a version
of the file that ends in "64" before the .so suffix.
In most unix-style LDAP servers, uid is a utf8 string defined by
OID 1.3.6.1.4.1.1466.115.121.1.15. However, sudoUser was defined
as an IA5 String (OID 1.3.6.1.4.1.1466.115.121.1.26) which meant
that sudoUser could only represent a subset of possible values.
In some cases when using sudoers.ldap, the uid from the machine
which was utf8 was fed back into sudo which would then issue a
search for sudoUsers. If this uid contained utf8 characters, the
ldap server would refuse to match into sudoUsers because these
were limited to IA5.
This is a safe-forward upgrade as IA5 is a subset of UTF8 meaning
that this change will not impact existing deployments and their
rules.