Operclass block

The operclass block is used to define ircop permissions. It is referred to from oper::operclass in the Oper block.

The operclass block allows you to define permissions in a very fine-grained manner. If you just want to use some good defaults, then see the default oper classses at the end of this article.

Syntax & Examples
operclass name { parent xyz; /* OPTIONAL: can be used to inherit permissions from another operclass block */ privileges { .....privileges to grant to this oper class...... }; };

Each operclass has a name. You define the privileges in operclass::privileges. Optionally you can use operclass::parent to have this operclass inherit all permissions from another operclass.

How privileges work
By default the oper using an operclass does not have special powers (this is not entirely true, actually). You must grant each privilege via operclass::privileges.

For example to grant the right to /KILL users: operclass name { privileges { kill; This would be the same as: operclass name { privileges { kill { allow; };

Many privileges allow you to define even more options, which go in a sub-block, like: operclass name { privileges { kill { allow { local yes; }; /* only allow KILL on local users, not remote */ }; You can also have multiple allow blocks. The following would permit SPAMFILTER, but only in a limited matter: operclass name { privileges { spamfilter { /* May delete ANY spamfilter */ allow { what del; };                       /* May add spamfilter with action 'block' */ allow { action block; };                       /* (all the rest is denied) */ };

Permissions available
Below is a list of all 100+ operclass permissions available. You may also be interested in looking at the default operclasses where we define a number of operclass blocks that are ready for you to use.

channel
These are channel-related permissions. See also override for operoverride.

channel:extbans
Can bypass set::restrict-extendedbans

channel:restricted
Can join channels which have a Deny channel block

channel:restrictedmodes
Can bypass set::restrict-channelmodes

channel:view
Allows you to view the topic of private channels (chanmode +p) without being in it, e.g. /topic #chan. Depending on client implementation this may or may not even be visible at all.

chat:globops
Can use /GLOBOPS

chat:locops
Can use /LOCOPS

chat:wallops
Can use /WALLOPS

client:dcc
Can use /DCCDENY

client:host
Can use /CHGHOST and /SETHOST

client:ident
Can use /CHGIDENT

client:ip
Can use /USERIP (a variant of /USERHOST.. meant for scripts)

client:name
Can use /CHGNAME

immune
These permit so called "immunities", various restrictions that normally apply to users but not to this oper (when enabled).

immune:antispamtimer
When doing /QUIT the set::set::anti-spam-quit-message-time won't apply.

immune:awayflood
Away flood settings (set::anti-flood::away-flood) do not apply to this user.

immune:channel:flood
If the channel is set +f with type 't' (eg: +f [5t]:15) then this limit won't apply to this oper, in other words: the user will not be kicked or kickbanned when sending lines too fast.

immune:channellimit
The maximum channels a user may join setting (set::maxchannelsperuser) does not apply to this user.

immune:forbiddenchan
May join channels which are normally forbidden by deny channel blocks.

immune:jointhrottle
Join flood settings (set::anti-flood::join-flood) do not apply to this user.

immune:limits
Nick flood settings (set::anti-flood::nick-flood) do not apply to this user. Also "target limit" is disabled (normally a user cannot send private messages to more than .. individual people per .. time).

TODO: this name is generic but the other anti-flood settings use specific names. Hmm.

immune:namecheck
Permit the use of banned real names.

TODO: actually next is necessary too, must merge (SETNAME vs CHGNAME)

immune:realnameban
Permit the use of banned real names.

immune:regonly
Can bypass channel mode +M (only registered users may speak).

TODO: move to override

immune:secureonly
Can bypass channel mode +z (only SSL users may join).

TODO: move to override

immune:shun
/SHUN and /TEMPSHUN on this oper won't have any effect.

immune:spamfilter
Spamfilters won't apply to this oper.

immune:viruschan
Can join the set::virus-help-channel. Normally only infected users can join.

kill
Can use /KILL

kill:global
Can use /KILL for users on another server

kill:local
Can use /KILL for users only on same server as the oper.

map:real-map
While normal users may see a "flat map" when doing /MAP, with this you will get to see the "real map" (which server linked to which).

map:ulines
Show ULines in /MAP (services servers).

notice
Can use /NOTICE $servermask for broadcasts to users.

notice:global
Can use /NOTICE $servermask for broadcasts to users on other servers

notice:local
Can use /NOTICE $servermask for broadcasts to users only on the local server

override
This allows IRCOps to bypass restrictions. Most (but not all) are channel-related which we call OperOverride.

override:message:prefix
PRIVMSG accepts a format like PRIVMSG @#chan :Hello to direct that message only to chanops and higher (according to specific rules, see below). With this privilege opers can override the prefix and use anything they want.

Normal prefix rules (i.e. without oper priv):
 * Need at least voice (+) in order to send to +, % or @
 * Need at least ops (@) in order to send to & or ~

override:mode
Allows opers to override the changing of channel modes without having the proper list mode.

override:mode:del
Allows opers to override the unsetting of channel modes (i.e. -i, -o someone) without having the proper list mode.

Seems to be ambiguous with override:mode or bugged even, as it also allows you to set any channel mode.

privacy
Allows /STATS L to user... TODO: this is not a good name.

privacy:fakelag
Disables fake lag for an oper. TODO: this is not a good name.

route
Permits /CONNECT and /SQUIT to link and unlink servers.

route:global
Allows the use of /CONNECT and /SQUIT on remote servers.

route:local
Allows the use of /CONNECT and /SQUIT only on the local server.

sajoin
Can use /SAJOIN

samode
Can use /SAMODE

sapart
Can use /SAPART

self:ident
Can use /SETIDENT (depends on settings)

server
Permits the use of various server management commands. Such as rehashing, restart, tsctl. In most cases you don't want to grant just all "server" privileges but only a limited set, see below.

server:addmotd
Can use /ADDMOTD

server:addomotd
Can use /ADDOMOTD

server:close
Can use /CLOSE to close any hanging / non-client connections

server:description
Can use /SDESC to change the server description

server:die
Can use /DIE to kill the server

server:dns
Can use /DNS to see resolver information

servicebot:deop
Allows you to /mode #chan -havoq protected users (umode +S). Only really useful when using custom bots, as (for example) Anope re-sets it automatically.

servicebot:kill
Allows you to /kill protected users (umode +S).

spamfilter
Can use /SPAMFILTER.

tkl
Can use Timed Kill Lines, like GLINE, KLINE, etc..

tkl:gline
Can use /GLINE

tkl:kline
Can use /KLINE

tkl:kline:local:add
Can add (but not remove) a KLINE on a local user

tkl:kline:remove
Can remove a KLINE

tkl:shun
Can use /SHUN

tkl:shun:temporary
Can use /TEMPSHUN

tkl:zline:global
Can use /GZLINE

tkl:zline
Can use /ZLINE

tkl:zline:local:add
Can add (but not remove) a ZLINE

trace
Can use /TRACE

trace:global
Can use remote /TRACE

trace:invisible-users
Show invisible users in /TRACE

trace:local
Only permit local /TRACE

Default oper classes
UnrealIRCd ships with a number of operclass blocks, these are in the file operclass.default.conf. You can use these for inspiration or just use them directly from your Oper block.

The default operclass blocks consist of:
 * locop: this has the least amount of privileges. The powers of this IRCOp type are (mostly) limited to the local server, for example it can /KILL and /KLINE local users but not remote users. This IRCOp does not have any special privileges in channels nor can it "see" much additional information of users. For example, they can see the IP of users (so they can /KLINE properly) but they cannot see if a user is in a secret channel (+s).
 * globop: Global IRC Operator. Has a good set of privileges. Can for example /KILL and /GLINE users on all servers. Can "see" extra things (override::see) such as secret channels in /LIST and /WHOIS.
 * admin: Server administrator. Similar to globop but includes the ability to use a few more potentially dangerous but powerful commands such as /SPAMFILTER.
 * services-admin: This level adds the ability to use /SAJOIN, /SAPART and /SAMODE.
 * netadmin: This is the highest level. Compared to services-admin it also includes the ability to deop or kill services bots and some other unusual things.

In addition to the above we also have globop-with-override, admin-with-override, services-admin-with-override and netadmin-with-override: these operclasses are the same as above but add the ability to use OperOverride. In other words: to walk through bans, changes modes without being op'ed, and so on. See OperOverride for more information.

Customizing oper classes
If you want to tweak an operclass, change a few permissions, then you can do so in two ways:
 * By copy-pasting the block(s) from operclass.default.conf
 * By creating a new operclass and using 'inheritance'. You set operclass::parent to an operclass to use as a base and then extend the operclass by adding / removing privileges.

We highly suggest you read below about both methods and only after that decide which one to use.

Copy-pasting
NOTE: You should never edit operclass.default.conf directly as it will be overwritten upon each upgrade! (hence the name operclass.default.conf)

This method is easy:
 * Copy the relevant block(s) to your own configuration file
 * Give the operclass block(s) a different name
 * Edit the block to add/remove privileges

The downside of this method is that when we add new privileges in later UnrealIRCd versions then your (custom) IRCOp classes won't have these rights by default. You would have to edit your operclass and add the new privileges manually (or not). This can happen when we move existing privileges that are currently granted to all IRCOps to a new privilege flag, or when we split existing privileges into 2 separate privileges. Since the operclass system is relatively new this is likely to happen (almost) every UnrealIRCd release. Of course, if you understand this downside and find it acceptable, then it's perfectly fine if you use this method.

Using inheritance
Inheritance works better than copy-paste (for small changes, anyway) and requires less maintenance on your side. This is because when we add new rights in UnrealIRCd in later versions we will add them to the default blocks and your customized block would automatically inherit them.

Inheritance should work well in the majority of the cases. However if you have a lot of changes then it may be better to just go for the copy-pasting method explained earlier.

Example
Say you like the locop operclass but want a few things changed:
 * You want the ircop to be able to 'see' extra things such as secret channels.
 * The locop class allows /ZLINE and /KLINE, but you want to only allow /KLINE.

operclass special { parent locop; /* we inherit the settings from 'locop' and then tweak them below.. */      privileges { /* we add a 'tkl' block with only 'kline', this means: only allow kline (and not zline too) */ tkl { kline; };

override { see; }; /* add the override::see capability */

/* all the other privileges are inherited from the 'locop' operclass */ }; };