Otherwise, sendto_channel_local_priv() will only distribute mode changes
to opers only. This is because HasPrivilege(target_p, "") will evaluate
as false due to the target not being opered.
Thanks to Devin Brown for bisecting this issue.
I'm preparing to PR a succession of privs changes with the ultimate goal
of severely limiting the scope of the binary oper/user dichotomy and
move conceptually distinct oper functions into their own privs.
Accomplishing this is a non-trivial task, and can wait, but it's
inconvenient now to have such functions enabled by the same mechanism
that grants any privs at all--so I'm moving all of them to a
transitional priv with the intention of eroding that later.
This removes some inconsistencies: first of all it applies to both
CONF_KILL searches by IP in find_address_conf, and secondly it applies
to find_kline, which would have been an edge case before.
rejectcache entries can now use either a K-line aconf or a static
string as a reason. This will be sent in a 465 numeric before the usual
ERROR. In the case of K-lines, it resembles the 465 you would have been
sent without being rejected:
; nc -s 127.6.6.6 127.0.0.1 5000
:staberinde.local 465 * :You are banned from this server- Temporary
K-line 4320 min. - abc123 (2019/12/31 01.07)
ERROR :Closing Link: (*** Banned (cache))
; nc -s 127.128.0.0 127.0.0.1 5000
:staberinde.local 465 * :You are not authorised to use this server.
ERROR :Closing Link: (*** Banned (cache))
to make the package build reproducible by default without
everyone having to discover the custom variable.
See https://reproducible-builds.org/ for why this is good
and https://reproducible-builds.org/specs/source-date-epoch/
for the definition of this variable.
This code assigns the plain integer to keep the code simple.
Otherwise we would have to deal with differences between GNU date
and BSD date or include extra build deps like perl or python.
/modrestart used to be implemented as a normal command and could crash
when used remotely because it would reload m_encap, which was on the
call stack at the time. This was fixed in 41390bfe5f. However,
/modreload has exactly the same problem, so I'm giving it the
same treatment.
Incidentally: This bug was first discovered in ircd-seven, where the
`/mod*` commands themselves live in the core, so m_encap was the only way
the crash could happen (and it didn't most of the time, because m_encap
would only be moved if you got unlucky). But `/mod*` are in modules in
charybdis, so /modrestart would have unloaded the code it was in the
middle of executing. With that in mind, I'm not sure how it ever
appeared to work.
Move opername and privset storage to struct User, so it can exist for
remote opers.
On /oper and when bursting opers, send:
:foo OPER opername privset
which sets foo's opername and privset. The contents of the privset on
remote servers come from the remote server's config, so the potential
for confusion exists if these do not match.
If an oper's privset does not exist on a server that sees it, it will
complain, but create a placeholder privset. If the privset is created by
a rehash, this will be reflected properly.
/privs is udpated to take an optional argument, the server to query, and
is now local by default:
/privs [[nick_or_server] nick]
As it stands, oper hiding is rather messy and inconsistent. Add
SeesOper(target, source), which is true iff target should appear as an
oper to source. If I haven't missed something, all commands that reveal
oper status now use the same logic.
general::hide_opers_in_whois is a special case, and affects /whois only.
general::hide_opers is introduced, and has the same effect as giving
everyone oper:hidden. All commands that reveal oper status respect both.
Reloading modules sends CAP DEL followed by an immediate CAP NEW:
:staberinde.local CAP * DEL :account-tag
:staberinde.local CAP * NEW :account-tag
This isn't very nice. /modrestart is particularly bad. In order to avoid
doing this, we remember the capability set at the beginning of module
operations, compare that with the set afterwards, and report only the
differences with CAP {DEL,NEW}.
When a server disconnects the client_exit hook will only be called once
but there could be multiple servers and clients behind that server.
After any client exits, check if the agent is still present.
This only supports two addresses as the intended use is 1 IPv4 and 1 IPv6
address on a single-homed host, and the only supported configuration of
outgoing connections to other servers is to bind a single IPv4 or IPv6
address.
Outgoing servers are not added to the client hash until they reach
IsServer() status, so if they're unknown when they exit then don't
attempt to delete them.
Set current_capmask and then use it, instead of referencing target_p->localClient->caps again.
This makes the purpose of current_capmask a bit clearer.
strlcpy should be called with the size of the destination buffer, not
the length of the source string.
When the source is an empty string, the destination buffer isn't
written at all, resulting in it trying to output uninitialised data.
This could also cause a buffer overflow on very long invalid config
lines.
ENCAP module. The ms_encap function is responsible for dispatching the
command handler and then the modules will eventually be reloaded.
However, if the ENCAP module is reloaded to a different address, the
stack now contains the address of a function that no longer exists.
Also, in this version of the IRCd, the module restarting functionality
was located in a function that is itself located in a module, so things
will also go badly if that module is reloaded to a different address,
too.
Return immediately from the command handler and have the event loop
call the function responsible for reloading the modules instead.
c.f. release/3.5 commit db05a36210
Reported-by: mniip (Freenode)
When both account-tag and server-time are present but the client
doesn't have the first (i == 0) of these enabled. They will get
an erroneous ';' after the '@'.
Track whether or not there are tags present, and use this to
determine whether to add the ';' or not. Also remove the extra
function that loops over all of the tags by using this flag to
handle the case where there are no tags being written.
Build the same message but send it to the local client first,
so that the echo-message capability works. But don't do it when
sending a message to yourself.
As well as leaking a connid and leaving the connection open,
these calls to free_client() leave the client in the unknown_list
causing check_unknowns_list() to crash when either ptr->data
(ptr being the freed client_p->localClient->tnode) is NULL or
when client_p->localClient is NULL.
Flag the client as an IO error so that we don't try to send it
any data (as this is not a normal plaintext connection).
==00:00:01:09.081 1762== 48 bytes in 2 blocks are definitely lost in loss record 545 of 991
==00:00:01:09.081 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.081 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.081 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.081 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.081 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.081 1762== by 0x4E52AC3: init_cache (cache.c:67)
==00:00:01:09.081 1762== by 0x4E69530: charybdis_main (ircd.c:762)
==00:00:01:09.081 1762== by 0x400815: main (main.c:8)
==00:00:01:09.100 1762== 2,808 bytes in 117 blocks are definitely lost in loss record 960 of 991
==00:00:01:09.100 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.100 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.100 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.100 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.100 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.100 1762== by 0x4E5337A: load_help (cache.c:301)
==00:00:01:09.100 1762== by 0x4E698AA: charybdis_main (ircd.c:848)
==00:00:01:09.100 1762== by 0x400815: main (main.c:8)
==00:00:01:09.100 1762== 5,328 (5,304 direct, 24 indirect) bytes in 221 blocks are definitely lost in loss record 971 of 991
==00:00:01:09.100 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.100 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.100 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.100 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.100 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.100 1762== by 0x4E53278: load_help (cache.c:266)
==00:00:01:09.100 1762== by 0x4E698AA: charybdis_main (ircd.c:848)
==00:00:01:09.100 1762== by 0x400815: main (main.c:8)
==01:17:20:36.920 5966== 429 bytes in 3 blocks are possibly lost in loss record 899 of 1,020
==01:17:20:36.920 5966== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.920 5966== by 0x4E73867: rb_strdup (rb_memory.h:70)
==01:17:20:36.920 5966== by 0x4E7674C: conf_set_connect_fingerprint (newconf.c:1421)
==01:17:20:36.920 5966== by 0x4E78D55: conf_call_set (newconf.c:2562)
==01:17:20:36.920 5966== by 0x4E6A33D: yyparse (ircd_parser.y:215)
==01:17:20:36.920 5966== by 0x4E7FFC7: read_conf (s_conf.c:834)
==01:17:20:36.920 5966== by 0x4E81718: read_conf_files (s_conf.c:1419)
==01:17:20:36.920 5966== by 0x4E69567: charybdis_main (ircd.c:775)
==01:17:20:36.920 5966== by 0x400815: main (main.c:8)
==01:17:20:36.919 5966== 280 bytes in 8 blocks are definitely lost in loss record 876 of 1,020
==01:17:20:36.919 5966== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.919 5966== by 0x4E93F4F: rb_strdup (rb_memory.h:70)
==01:17:20:36.919 5966== by 0x4E95280: ssl_process_cipher_string (sslproc.c:476)
==01:17:20:36.919 5966== by 0x4E95540: ssl_process_cmd_recv (sslproc.c:561)
==01:17:20:36.919 5966== by 0x4E9582A: ssl_read_ctl (sslproc.c:632)
==01:17:20:36.919 5966== by 0x56CBAB6: rb_select_epoll (epoll.c:199)
==01:17:20:36.919 5966== by 0x56C4EB5: rb_select (commio.c:2085)
==01:17:20:36.919 5966== by 0x56C7FD6: rb_lib_loop (rb_lib.c:228)
==01:17:20:36.919 5966== by 0x4E69987: charybdis_main (ircd.c:872)
==01:17:20:36.919 5966== by 0x400815: main (main.c:8)
==01:17:20:36.906 5966== 48 bytes in 1 blocks are definitely lost in loss record 544 of 1,020
==01:17:20:36.906 5966== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.906 5966== by 0x4E93F0C: rb_malloc (rb_memory.h:41)
==01:17:20:36.906 5966== by 0x4E961E8: start_zlib_session (sslproc.c:901)
==01:17:20:36.906 5966== by 0x4E86FAC: server_estab (s_serv.c:877)
==01:17:20:36.906 5966== by 0x13B2921A: mr_server (m_server.c:304)
==01:17:20:36.906 5966== by 0x4E7AF03: handle_command (parse.c:241)
==01:17:20:36.906 5966== by 0x4E7A96A: parse (parse.c:157)
==01:17:20:36.906 5966== by 0x4E7A3DC: client_dopacket (packet.c:354)
==01:17:20:36.906 5966== by 0x4E798D6: parse_client_queued (packet.c:98)
==01:17:20:36.906 5966== by 0x4E79FAC: read_packet (packet.c:282)
==01:17:20:36.906 5966== by 0x56CBAB6: rb_select_epoll (epoll.c:199)
==01:17:20:36.906 5966== by 0x56C4EB5: rb_select (commio.c:2085)
[ircd/match.c:316]: (error) Shifting a negative value is undefined behaviour
[librb/src/patricia.c:55]: (error) Shifting a negative value is undefined behaviour
[modules/m_alias.c:64]: (portability) '(void*)message' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[modules/m_time.c:111]: (warning) %u in format string (no. 9) requires 'unsigned int' but the argument type is 'signed int'.
[modules/m_time.c:111]: (warning) %u in format string (no. 10) requires 'unsigned int' but the argument type is 'signed int'.
[librb/src/dictionary.c:819]: (warning) %d in format string (no. 3) requires 'int' but the argument type is 'unsigned int'.
[librb/src/radixtree.c:1080]: (warning) %d in format string (no. 3) requires 'int' but the argument type is 'unsigned int'.
[ircd/s_user.c:351] -> [ircd/s_user.c:357]: (warning) Either the condition '0!=source_p' is redundant or there is possible null pointer dereference: source_p.
[extensions/ip_cloaking_3.0.c:109]: (warning, inconclusive) The buffer 'buf' may not be null-terminated after the call to strncpy().
[ircd/chmode.c:256]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_help.c:100]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_knock.c:169]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_stats.c:628]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_stats.c:727]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:601]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:704]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:739]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:763]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:768]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:774]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:781]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:786]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:791]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:804]: (style) Clarify calculation precedence for '&' and '?'.
[ircd/wsproc.c:372]: (style) Unused variable: len
[modules/core/m_modules.c:382]: (style) Unused variable: i
[modules/m_stats.c:741]: (style) Unused variable: amsg
[ircd/authproc.c:390]: (style) Unused variable: iter
[ircd/authproc.c:391]: (style) Unused variable: client_p
Links that are 'no-export' are not distributed to the rest of the IRC network (including local peers).
This provides a core primitive for 'anycasting' services (but the actual issue of synchronizing data in
a services package is left to the authors of the services package).
On FreeBSD 4.8, fork(2) doesn't actually behave like fork(2).
Namely, kqueue(2) descriptors are not inherited by the child.
IOW, we can't fork(2) after we get the kqueue(2) descriptor.
So we'll just have to rely on people to actually read the
server log file if they want to understand why their server
is dying during startup.
