Operclass block

From UnrealIRCd documentation wiki
Jump to: navigation, search

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.

Contents

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:operonly

channel:operonly:topic

channel:remotebanlist

channel:remoteinvexlist

channel:remoteownerlist

channel:restricted

Can join channels which have a Deny channel block

channel:restrictedmodes

Can bypass set::restrict-channelmodes

channel:topic

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:banpartmsg

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.

immune:viruscheck

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:ban:operonly

override:channel:invite

override:extban

override:invite:nopermissions

override:invite:notinchannel

override:kick

override:kick:nokick

override:kick:owner

override:message:ban

override:message:moderated

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:message:regonly

override:message:regonlyspeak

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.

override:nick:flood

override:nick:qline

override:privsecret

override:secure

override:see:list:secret

override:see:names:invisible

override:see:names:secret

override:see:whois

override:see:who:onchannel

override:topic

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:getbaddcc

self:ident

Can use /SETIDENT (depends on settings)

self:restrictedumodes

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

server:info

server:info:lag

server:info:lusers

server:module

server:opermotd

server:rehash

server:remote

server:restart

server:tsctl

server:tsctl:set

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.

stats:viewinvisible

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 */
       };
};