The "ServiceMask" variable in "Server" blocks now can handle more than
one mask using the new MatchCaseInsensitiveList() function.
This makes marking "service clients" much more specific, which is a
good thing per se, but which is the prerequisite for reasonably
blocking these nick names, too (see commit a6dd2e3 for details).
This patch introduces the new function Conf_NickIsBlocked() which checks
if a given nick name matches with the "service mask" of a configured server.
And Client_CheckNick() uses this information to deny such names for regular
IRC users.
So nick names intended for IRC services are more protected and can't be used
by regular users even when the "services pseudo-server" isn't connected to
the network.
But please note:
Up to now, there can be only one "ServiceMask" pattern per server, which
most probably blocks much more nick names than really required ...
So "ServiceMask" should allow more than one pattern which can be more
specific, and most probably it should be possible to block nick names in
the global server configuration as well.
Nick names introduced by other servers/services are never restricted.
This is a relatively naive implementation, basically doing the bare minimum
necessary to make the switchover go. Subsequent commits can focus on
improving the implementation.
3 new channel user modes have been added.
Half Op: +h(Prefix: %) can set the channel modes +imntvIbek
and kick all +v and normal users.
Admin: +a(Prefix: &) can set channel modes +imntvIbekoRsz and kick all
+o, +h, +v and normal users.
Owner: +q(Prefix: ~) can set channel modes +imntvIbekoRsz and kick all
+a, +o, +h, +v and normal users
Implemented support for hashed hostnames for CloakHost. The admin can
use '%x' in both the CloakHost and CloakHostModeX setting. The config
option CloakHostModeX was renamed to CloakHostSalt. This salt is used
for both cloaking options.
CloakHostModeX can now contain '%x'. It will be replace by the hash of
the original client hostname. The new config option CloakHostModeXSalt
defines the salt for the hash function. When CloakHostModeXSalt is not
set a random salt will be generated after each server restart.
Spelling fix in defines.h
Don't try to establish an outgoing server link after DNS lookup when this
server re-connected on its own in the meantime.
In addition, log a warning message if we try to update the connection
index of an already connected server structure -- and ignore it.
Up to now, both behaviour could lead to a race when the remote server
connects to this daemon while it still prepares the outgoing connection:
- The local server prepares the new outgoing connection ...
- in the meantime the remote server becomes connected and registered.
- Now the new outgoing connection overwrites the (correct) socket handle,
- then the 2nd connection becomes disconnected: "already registered",
- and the 1st connection becomes unhandled ("gets lost") because the
configuration structure is reset because of the wrong socket handle.
This patch hopefully fixes all these problems.
Only alphanumeric characters are allowed in the user name, so ignore
all IDENT replies that would violate this rule and use the one supplied
by the USER command.
Only alphanumeric characters are allowed in the user name, so terminate
the connection if any "strage" characters have been supplied by the user.
This is how other IRC daemons (like ircd2.11 and ircd-seven) behave ...
This fixes the following warnings with GCC 4.4.5 on Linux:
irc-login.c: In function ‘IRC_PASS’:
irc-login.c:92: warning: implicit declaration of function ‘strlen’
irc-login.c:92: warning: incompatible implicit declaration of built-in function ‘strlen’
irc-login.c:113: warning: incompatible implicit declaration of built-in function ‘strlen’
irc-login.c:129: warning: implicit declaration of function ‘strchr’
irc-login.c:129: warning: incompatible implicit declaration of built-in function ‘strchr’
irc-login.c:133: warning: implicit declaration of function ‘strcmp’
irc-login.c: In function ‘IRC_SERVICE’:
irc-login.c:556: warning: incompatible implicit declaration of built-in function ‘strchr’
login.c: In function ‘Login_User’:
login.c:131: warning: implicit declaration of function ‘strcmp’
* capabilities:
"multi-prefix" capability 2/2: adjust NAME and WHO handlers
"multi-prefix" capability 1/2: implement complete CAP infrastructure
IRC_Send_NAMES(): Code cleanup
New function Client_CapSet() in addition to Client_Cap{Add|Del}
"CAP REQ" starts capability negotiation and delays user registration
Correctly handle "CAP END", new client type CLIENT_WAITCAPEND
Implement core IRC capability handling and "CAP" command
New "login" source file
Introduce_Client() => Client_Introduce(), and move it to client.c
Now ngIRCd is able to handle "CAP LS", "CAP REQ", "CAP LIST", and
"CAP CLEAR" commands.
"multi-prefix" can be set/unset, but has no functionality - yet!
This fixes the following warning of clang:
/src/ngircd/lists.c:152:44:
warning: size argument in 'strlcpy' call appears to be size of the
source; expected the size of the destination [-Wstrlcpy-strlcat-size]
But it isn't a real problem, because the size of the source always is the
same than the size of the destination ...
This patch implements the core functions to support "IRC Capabilities"
and the IRC "CAP" command as used by other servers and specified here:
<http://www.leeh.co.uk/draft-mitchell-irc-capabilities-02.html>.
It enables ngIRCd to support the defined handshake, but it doesn't
implement any capabilities, so "CAP LS" and "CAP LIST" always return
the empty set and "CAP REQ ..." always fails with "CAP NAK".
Rename Hello_User[_PostAuth] to Login_User[_PostAuth] and move it to the
new login.c; and move cb_Read_Auth_Result(), too. This will enable further
code to easily call Login_User() when required.
Up to now, ngIRCd silently ignored permission denied errors when trying
to enable a chroot setup: only the "not running chrooted" message became
logged later on.
This patch lets ngIRCd exit with a fatal error when the chroot can't
be enabled on startup -- this is the much safer bevahiour!
This fixes the following warning with gcc 4.6.3.:
irc-mode.c: In function "Channel_Mode":
irc-mode.c:947:26: error: "list" may be used uninitialized
in this function
irc-mode.c:884:25: error: "list" may be used uninitialized
in this function
(The variable has never been used uninitialized, so don't worry)
When
* building the ngircd Debian package (on Linux at least) and
* using the sbuild build system,
the command "ps -af" does not include the commands running inside the
sbuild system. Therefore, start-server.sh will report a fail as getpid.sh
cannot not find the ./T-ngircd1 just started although it's actually
running. This results in a funny build log ...
starting server 1 ... failure!
FAIL: start-server1
running connect-test ... ok.
PASS: connect-test
The self-test of getpid.sh however will likely succeed as it's happy if
it sees any process with "sh" somewhere in the name. Things go downhill
from there.
The confusing things are:
* The alternative cowbuilder/pbuilder does not have this problem.
* The alternative usage "ps ax" does fine.
So, as a quick hack, the patch attached adds another switch to getpid.sh.
Start "regular" logging not until the configuration file has been read in
and "SyslolgFacility" is set, and log all configuration errors using the
generic "daemon" facility.
So if there are no configuration errors, logging starts right after parsing
the configuration and we log the configuration file used _after_ reading it.
But this is no problem because every configuration error message includes
the configuration file name as well.
(The "double hello" has been introduced by commit 3641e51109)
Syslog logging has been initialized before reading the configuraton
file, so ngIRCd always used the default facility and ignored the
"SyslogFacility" configuration option.
Thanks to Patrik Schindler for reporting this issue!
This patch updates the limits for handling commands from a remote server:
- "<user count> / 5 + <min>" using "<min>=10" during normal operation,
- the above count multiplied with 5 while servers are syncing.
The intention is to a) make the limit dependent of the number of users
in the network (the more users, the more commands required to sync) and
b) to significantly rise this limit while servers are joining the network
to make the login and synchronization faster.
At the end of sending all "state" to the remote server, a PING command
is sent to request a PONG reply. Until then, no "regual" PING was sent,
so Conn_LastPing(<connection>) is null and now becomes non-null in the
PONG command handler.
So the servers are still synchronizing when Conn_LastPing(<connection>)
is 0, which could easily be tested.
The numeric RPL_WHOISHOST_MSG(378) returns the DNS hostname (if
available) and the IP address of a client in the WHOIS reply.
Only the user itself and local IRC operators get this numeric.
This allows to use "*!<user>@<host>" or "*!*@<host>" masks to reject
clients even before receiving PASS, NICK and USER commands and before
forking authentication child processes which reduces resource usage.
This allows a channel operator to define exception masks that allow users
to join the channel even when a "ban" would match and prevent them from
joining: the exception list (e) overrides the ban list (b).
If the target user of a PRIVMSG or NOTICE command has the user mode 'C'
set, it is required that both sender and receiver are on the same channel.
This prevents private flooding by completely unknown clients.
- Check correct list for duplicates when adding items.
- Don't generate any messages when adding duplicates or removing
non-existing items (this is how ircd-seven and ircu behave).
- Code cleanup: Add_Ban_Invite(), Del_Ban_Invite().
Commit 565523cb allowed processing of further channel names given to the
JOIN command when a single name was invalid.
After this patch, the JOIN command handler continues to process channel
name lists even after errors like "channel is full", "too many channels",
and the like and generates appropriate error messages for all the
channels given by the client.
Limit the MODE command to handle a maximum of MAX_CMODES_ARG (5) channel
modes that require an argument (+Ibkl) per call.
Please note: Further modes that require arguments are silently ignored
and end the handling of any further modes.
This is similar to the behavior of ircd2.11 (silently ignores but seems
to handle other modes) as well as ircd-seven (silently ignores but handles
some(!) other modes) ...
The assert(client != NULL) got triggered during our tests, so there is
an error path that resulted in the connection being still established
(sock >= 0) but the client structure already freed.
So Conn_Write() should handle it!
This reduces the possibility of flooding channels with commands like
"PRIVMSG/NOTICE #a,#n,#c,... :message" a little bit.
Problem noticed by Cahata -- thanks!
Until now, the penalty time has only been set when longer as the
already set one, so it didn't accumulate.
And add documentation for and clean up code in Conn_SetPenalty() and
Conn_ResetPenalty() functions.
This partly closes bug #118. ngIRCd still starts up even when
Server{UID|GID} is invalid: then the daemon falls back to "nobody"
when running with root(0) privileges (as before).
commit 15fec92ed7
(Update list item, if it already exists) can make ngircd
crash because 'Reason' can be NULL, as reported by
Cahata on the ngircd mailing list.
Doesn't affect any released ngircd versions.
Also, make sure that we do not pass NULL as arguments
to a '%s' printf-like function.
When JOIN is received with more than one channel name, don't stop
processing on the first error (e.g. bad name, wrong channel key, ...)
but report an error and continue with the other given channel names.
Reported by Cahata -- thanks!
When "PAMIsOptional" is set, clients not sending a password are still
allowed to connect: they won't become "identified" and keep the "~"
character prepended to their supplied user name.
This fixes two bugs:
- "WHO <nick>" returned nothing at all if the user was "+i"
(reported by Cahata, thanks).
- "WHO <nick|nickmask>" returned channel names instead of "*"
when the user was member of a (visible) channel.
Clean up code and add documentation as well.
Rename Channel_Count() to Channel_CountVisible() and only count channels
that are visible to the requesting client, so the existence of secret
channels is no longer revealed by using LUSERS.
Reported by Cahata -- thanks!
Unknown user and channel modes no longer stop the mode parser, but are
simply ignored. Therefore modes after the unknown one are now handled.
This is how ircd2.10/ircd2.11/ircd-seven behave, at least.
Reported by Cahata -- thanks!
This fixes:
irc-oper.c: In function ‘IRC_xLINE’:
irc-oper.c:429: warning: ‘class’ may be used uninitialized in this function
irc-oper.c:430: warning: ‘class_c’ may be used uninitialized in this function
