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 */ permissions { .....permissions to grant to this oper class...... }; };

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

How permissions 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::permissions.

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

Many permissions allow you to define even more options, which go in a sub-block, like: operclass name { permissions { 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 { permissions { spamfilter { /* May delete ANY spamfilter */ allow { what del; };                       /* May add spamfilter with action 'block' */ allow { action block; };                       /* (all the rest is denied) */ };

Permissions list
See the Operclass permissions article for an overview and the full list of 100+ permissions that are available.

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 permissions.

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 permissions

The downside of this method is that when we add new permissions 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 permissions manually (or not). This can happen when we move existing permissions that are currently granted to all IRCOps to a new privilege flag, or when we split existing permissions into 2 separate permissions. 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 1: limit rights
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.. */      permissions { /* 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 permissions are inherited from the 'locop' operclass */ }; };

Example 2: super-netadmin
In this example we will extend the netadmin IRCOp to also restart the server (via the /RESTART command).

The restart privilege is called server::restart. So we need to override the server privilege. First, you should have a look at which server permissions are there in the netadmin class. You should check out operclass.default.conf, but at the time of writing this article it is: server { opermotd; info; close; remote; module; dns; addline; rehash; description; addmotd; addomotd; tsctl; };

So we will need to add restart; to that.

This is the complete block you will use:

operclass super-netadmin { parent netadmin; /* we inherit the settings from 'netadmin' and then tweak them below.. */      permissions { /* we are going to change the 'server' block. We need to copy the rights from * the 'netadmin' operclass and add 'restart' to it: */               server { opermotd; info; close; remote; module; dns; addline; rehash; description; addmotd; addomotd; tsctl; restart; };               /* all the other permissions are inherited from the 'netadmin' operclass */ }; };