Alan T. DeKok [Mon, 27 Jan 2025 13:35:11 +0000 (08:35 -0500)]
remove radutmp, radlast, radwho, and radzap
Many OS's have moved away from using flat-text files for utmp.
Some don't even provide utmp functionality or header files.
I can't remember the last time I ran into someone using radutmp,
even in v3. And I can't recall ever designing a system with
radutmp. It's 2025, and people should use sqlite instead.
Alan T. DeKok [Sun, 26 Jan 2025 15:38:03 +0000 (10:38 -0500)]
cleanups of expression and condition parsing
we need quotes around bare words in more places.
Any explicit cast is NOT passed down when parsing the next thing.
Instead, the next thing is parsed as-is, and then the cast is
applied by the current function. This cleans up a lot of odd cases.
Also add more checks for different tmpl types when casting things
Add '#if 0' out code to complain on unresolved data when parsing.
Changing that will require a bunch of other updates, to add quotes
around bare words.
the tmpl_resolve() function would treat unresolved data as either
enums or strings. That will be changing to require either '::'
prefix on enums, OR quotes around non-attribute bare words.
So (ippadr)* is now invalid, as "*" can't be parsed by
tmpl_afrom_substr(). Instead, we must use (ipaddr)'*'
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.