We only want to pass the execution environment back for commands
that are accepted or rejected.
Also avoid potentially freeing the wrong pointer when garbage
collection is enabled.
Previous, sudo would always allow unknown user or group IDs if the
sudoers entry permitted it. This included the "ALL" alias.
With this change, the admin must explicitly enable support for unknown IDs.
Some admin are confused about how to give users sudoedit permission
and many users try to run sudoedit via sudo instead of directly.
If the user runs "sudo sudoedit" sudo will now treat it as plain
"sudoedit" after issuing a warning. If the admin has specified a
fully-qualified path for sudoedit in sudoers, sudo will treat it
as just "sudoedit" and match accordingly. In visudo (but not sudo),
a fully-qualified path for sudoedit is now treated as an error.
If the umask is explicitly set in sudoers, use that value regardless
of what is in PAM or login.conf. If using the default umask from
sudoers, allow PAM or login.conf to override it. Bug #900
By default, sudo relies soley on group permissions to read sudoers
to make it possible to store sudoers on NFS. However, if /etc/sudoers
is not accessible to non-root uids for some reason, sudo will fail.
Bug #880.
1) don't assume snprintf() returns -1 on error, check for <0
2) when comparing return value of sizeof(foo), cast the sizeof, not the len
3) cast return value to void in cases where snprintf cannot fail
we are listing in short mode (in which case we convert them to tags
if possible). Fixes a problem where sudoOptions were not being
applied to the command.
o The parse tree is now passed to the alias, match and defaults functions.
o The nss API has been changed so that the nss parse() function returns
a pointer to a struct sudoers_parse_tree which will be filled in
by the getdefs() and query() functions.
in a per-nss list of userspecs and defaults instead of using separate
lookup and list functions. This makes it possible to have a single
implementation of the code for sudoers lookup and listing.
false (since the user didn't authenticate). The normal reason for
this is an authentication error but in this case no authentication
was tries so no warning message has been displayed to the user. If
the user wasn't given a chance to authenticate, set inform_user to
true when calling log_denial() from sudoers_policy_main().
An alternate approach would be for check_user() to return true
in this case but seems more confusing.
This effectively reverts ed77d255f383.
We treat the SUDO_PROMPT environment variable similar to passprompt
in sudoers: it will only override a PAM prompt if the PAM prompt
is either "Password:" or "username's Password:".
