Currently, we generate the signal list and names by running cpp on our
header, and piping the result into sed.
However, when cpp fails [0], we do not catch that failure, as the error
code of the LHS of a pipe is lost, with the pipe returning the RHS-most
return code.
Fix that by introducing two new intermediate rules, each to generate the
preprocessed .i files, and use those as dependencies and input to the
rule that generates the headers. Those two .i files will be cleaned up
by the existing *.i glob.
[0] a failure happens on recent hosts, due to inconsistency with
time64_t and large-file support (lines elided and wrapped for
readability):
/usr/bin/cpp [...] ./sys_signame.h \
| /usr/bin/sed -e '1,/^int sudo_end_of_headers;/d' -e '/^#/d' > mksigname.h
In file included from /usr/include/features.h:394,
from /usr/include/sys/types.h:25,
from ./sys_signame.h:4:
/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
| ^~~~~
/usr/bin/gcc [...] ./mksigname.c -o mksigname
In file included from /usr/include/features.h:394,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdlib.h:26,
from ./mksigname.c:27:
/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
| ^~~~~
make[2]: *** [Makefile:263: mksigname] Error 1
In that case, we were lucky that the subsequent gcc call also failed,
and for the same reason. That time64_t and lfs issue should be fixed (at
least investigated), but that does not mean we should not be more robust
when parsing the header either.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 32f4b98f6b4a (sudo frontend: silence most -Wconversion warnings.)
broke the build on C libraries that miss process_vm_readv(), like
uClibc-ng.
Indeed, the ssize_t nwritten is declared guarded by HAVE_PROCESS_VM_READV,
but is then re-assigned and used a few lines below, outside any guard.
Fix that by always declaring the object, as it is always needed.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This means that it is not logged for "sudo -nv" and "sudo -nl".
We only log this message when sudo's -n flag is specified (and not
when the user presses ^C at the password prompt) so that there is
a record of failed non-interactive commands.
This is a bug in parse_default_entry() introduced in sudo 1.8.19
when support for using the default syslog facility was added at the
wrong place in a switch().
--HG--
branch : 1.9
This is a bug in parse_default_entry() introduced in sudo 1.8.19
when support for using the default syslog facility was added at the
wrong place in a switch().
Previously, a tuple in boolean context was always treated as a
negated entry, which doesn't match the documentation. We assume
that there are at least two tuple entries where the first maps to
boolean false and the second maps to boolean true.
--HG--
branch : 1.9
Previously, a tuple in boolean context was always treated as a
negated entry, which doesn't match the documentation. We assume
that there are at least two tuple entries where the first maps to
boolean false and the second maps to boolean true.
