The parser will use that when reporting on an ERROR state. This
prevents the lexer from reporting errors about tokens that are not
actually consumed by the parser and we don't have to worry about
both the lexer and the parser reporting errors. It also means we
only get one error per sudoers line.
We need to be able to display it using alias_error().
Only free what we actually allocated in alias_add() on error and
let the caller handle cleanup. Note that we cannot completely fill
in the alias until it is inserted. Otherwise, we will have modified
the file and members parameters even if there was an error.
As a result, we have to remove those from the leak list after
alias_add(), not before.
We now need to remove the name and members from the leak list
*before* calling alias_add() since alias_add() will consume them
for both success and failure.
This is used to provided the column number along with the line
number in error messages. For aliases we store the column of the
alias name, not the value since that is what visudo generally needs.
A valid line in sudoers must end in a newline or EOF.
Previously, it was possible (though not documented) to have multiple
user specs on a single line. Now, each must be on its own line.
The ERROR token is now only used for errors detected by the lexer
and for which we've already printed an error. This lets us remove
the hack in sudoerserror() and just check last_token to determine
whether or not to display the error.
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.
Previously we needed to include headers required by the various
sudo*h files. Now those files are more self-sufficient and we
should only include headers needed by code in the various .c files.
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.
