Alan T. DeKok [Wed, 22 Jan 2025 15:30:12 +0000 (10:30 -0500)]
allow adding files to dictionaries
without specifying the full dictionary path. It doesn't make a lot
of sense to load "radius/foo" when the function is being asked to
load the file into the RADIUS dictionary
Alan T. DeKok [Tue, 21 Jan 2025 01:56:25 +0000 (20:56 -0500)]
handle ATTRIBUTE flag better.
If the flag is set, then the data _must_ be parsed as an attribute.
In which case we just call the tmpl_afrom_attr_str() function,
instead of calling the generic tmpl_afrom_substr() function.
and then complaining if the parsed tmpl wasn't an attribute.
Alan T. DeKok [Sun, 19 Jan 2025 11:24:31 +0000 (06:24 -0500)]
more debugging, and parse RHS as attribute for new code
debugging lets us see exactly which stage of parsing failed.
when tmpl_require_enum_prefix=yes, AND we can't parse the RHS
as an enum, or other data type, then try to parse it as an
attribute.
This means that if the RHS string is unquoted, and is accidentally
the same as an attribute name, then it will get parsed as an
attribute reference.
It's not clear what the best solution is here. In order to
differentiate the two types of data, either have to:
a) forbid bare words except for attribute names
which means requiring that all strings including passwords
are quoted. This seems unfriendly.
b) allow '&' on the RHS, in order to separate it from bare word
strings. But then if a password begins with '&', it will be
treated as an attribute reference
c) change the operator to one which explicitly signals that the
RHS is an attribute. Perhaps by tacking on '&' after the
operator? Which seems fugly.
Alan T. DeKok [Sat, 18 Jan 2025 21:40:44 +0000 (16:40 -0500)]
Without &, bare words are more often attribute references.
Add a flag to the call_env API which says that this thing might
be an attribute reference, but only if it's a bare word. And it's
not _required_ to be an attribute reference.
Update rlm_linelog to use the new flag.
Now that we can't key off of '&' to say "bare word is an attribute",
we must instead use a slightly more complex method.
James Jones [Sun, 12 Jan 2025 20:51:22 +0000 (14:51 -0600)]
Handle edge case in fr_rand_init() and, we suspect, oveflow (CID #1604611) (#5434)
To handle the rare case of not filling fr_rand_pool.randrsl in a single read,
adjust the location passed to read() to skip what was read in a previous
interation. This is done in a way consistent with the handling of this case
in 3.x, which should also deal with the overflow_sink complaint from Coverity.
James Jones [Sun, 12 Jan 2025 20:49:36 +0000 (14:49 -0600)]
Annotate return_overflow in mod_write() (CID #1604620) (#5437)
This is arguably another example of trying to return a value not
representable in the function return type. It's highly unlikely that
anyone will pass a buffer of more than SSIZE_MAX bytes, but Coverity
apparently doesn't consider that.
CIDs #1604605 and #1604616 explicitly do return error values not
representable as int, but a ridiculously large buffer allocation will
fail long before anyone calls mod_write(), so we annotate.
James Jones [Sun, 12 Jan 2025 20:49:14 +0000 (14:49 -0600)]
Annotate return_overflow in fr_writev() (CID #1604625) (#5438)
In theory, iovcnt and the amounts written could total to more than
SSIZE_MAX, and when Coverity is looking at fr_writev() rather than
its callers it can't tell. We therefore annotate.
James Jones [Sun, 12 Jan 2025 20:48:01 +0000 (14:48 -0600)]
Switch Coverity-only code to assert (CID #1619299) (#5441)
fr_nbo_from_uint64v() does not have an error return--it doesn't
need one. The buffers are big enough, the "| 0x80" means it will
always use as least one byte, so fr_high_bit_pos() won't return 0
even if num == 0. So adding a bogus error return check for Coverity
actually misleads Coverity about any call to fr_nbo_from_uint64v(),
making it the probable cause of the CID.
Alan T. DeKok [Fri, 10 Jan 2025 21:44:23 +0000 (16:44 -0500)]
set "yes" to "1" and "auto" to "2"
The configuration file parsing code parses things before it knows
their data types. Which means that "yes" gets parsed as data type
"bool", with value "1". It then gets cast to "uint8_t" when
processing the require-ma attribute. Which just happens to have
"auto" as "1", and "yes" as "2".
Rather than redoing all of the parsing code, we just set "yes"
to "1", which is much safer.