Only check the channel user modes of the initiator if he is joined to
this channel and not an IRC operator enforcing modes (which requires
the configuration option "OperCanUseMode" to be enabled), because trying
to check channel user modes of a non-member results in this assertion:
Assertion failed: (cl2chan != NULL), function Channel_UserModes,
file channel.c, line 742.
This closes bug #147, thanks to James Kirwill <james.kirwill@bk.ru>
for tracking this down!
Now ngIRCd uses two fields internally, one to store the "real" hostname
and one to save the "cloaked" hostname. And both fields can be set
independently using the "METADATA host" and "METADATA cloakhost" commands.
This allows "foreign servers" (aka "IRC services") to alter the real and
cloaked hostnames of clients without problems, even when the user itself
issues additional "MODE +x" and "MODE -x" commands.
Use "METADATA host" commands to let servers supporting this command
know which (possibly cloaked) hostname is in effect for a specific
client. This prevents "double cloaking" of hostnames and even cloaked
hostnames are in sync on all servers supporting "METADATA" now.
When a user has set mode "b", all private messages and notices to this
user are blocked if they don't originate from a registered user, an IRC Op,
server or service. The originator gets an error numeric sent back in this
case, ERR_CANNOTSENDTONICK_MSG(976), which is/was(?) used by KineIRCd, too.
This closes bug #144.
If the new channel mode "V" is set, the INVITE command becomes invalid
and all clients get the new ERR_NOINVITE_MSG(518) reply.
Unreal and InspIRCd uses this mode, too.
This closes bug #143.
This patch fixes unsetting of channel user mode "+a" (channel admin)
and adds a better error message: without this patch, a channel admin is
unable to unset this mode.
This closes bug #142.
Both modes protect users from channel kicks: only IRC operators and
servers can kick users having mode "q" or in channels with mode "Q".
Original patch by DNS777 <dns@rbose.org>, thanks!
This closes bug #141.
Allow users to "cloak" their hostname only when the configuration
variable "CloakHostModeX" (introduced in 19.2) is set. Otherwise, only
IRC opertators, other servers, and services are allowed to set mode +x.
This prevents regular users from changing their hostmask to the name
of the IRC server itself, which confused quite a few people ;-)
This fixes bug #133.
* 'xop' of https://github.com/kart0ffelsack/ngircd:
Tests and documentation for xop
Implemented xop support
Conflicts (because of merge of the 'cmode-M' branch):
src/ngircd/channel.c
src/ngircd/defines.h
src/ngircd/messages.h
This numeric is sent to the client each time it changes its displayed
hostname using "MODE +/-x", and if "CloakHost" is set right after the
MOTD has been sent.
This patch series allows ngIRCd to support the user mode "B" ("Bot flasg"):
it is settable and unsettable by every (non-restricted) client.
According to DNS777, this is how Unreal and InspIRCd do behave, so do we :-)
By Alexander Barton (1) and DNS777 (1)
* umode-B:
Add new user mode "B" to doc/Modes.txt
Implement an Unreal-like user mode "B" ("Bot mode")
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
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)
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().
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) ...
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!
- User mode "R": indicates that the nick name of this user is "registered".
This mode isn't handled by ngIRCd itself, but must be set and unset by
IRC services like Anope.
- Channel mode "R": only registered users (having the user mode "R" set)
are allowed to join this channel.
These channel user modes aren't used for anything at the moment, but
ngIRCd knows that these three modes are "channel user modes" and not
"channel modes", that is that these modes take an "nick name" argument.
Like unknown user and channel modes, these modes are saved and forwarded,
but ignored otherwise.
This generic function tests if a client is allowed to do administrative
tasks to a specific channel:
- servers and services are always truested ("allowed everything"),
- channel operators are allowed,
- IRC operarors are allowed if OperCanUseMode is set in the config.
When a client has user mode "x" set, its real hostname is cloaked
by substituting it with the server name (as configured in ngircd.conf).
Restricted clients (user mode "r") aren't allowed to change mode "x".
Please note that hostname cloaking is only in effect in server-client
communication! The server still uses the real hostname for its own
logging and for all server-server communication -- therefore all servers
in the network must support user mode "x" to prevent older servers
from leaking the real hostname of a cloaked client!