Special users

Sometimes you want to give trusted users or bots more rights or higher flood rates than regular users, but you don't want to make them IRCOp. This page explains how.

NOTE: The same method can also be used to give less rights to a group (so the other way around).

Define a security group

It starts with putting users you trust (or distrust) in a security group. Security groups can be based on IP addresses, but also on services accounts via account or certificate fingerprints via certfp. There are actually 15+ other criteria, for all see the Security-group block. There are also standard security groups like known-users and unknown-users (see the same article).

Let's define a security group for people we trust, and assume they all have a Services account and log in to that using SASL.

security-group staff {
        account {
                User1;
                User2;
                User3;
        }
}

Applying specific settings

In UnrealIRCd 6.1.1 and higher you can create a specific set block for the security-group:

set staff {
        maxchannelsperuser 50;
}

The following settings can be overridden in a set block for a security group:

• set::auto-join
• set::modes-on-connect
• set::restrict-usermodes
• set::maxchannelsperuser
• set::static-quit
• set::static-part

You can also set specific set::anti-flood settings, see next section.

Overriding anti-flood settings

You can use the set::anti-flood block to give higher flood limits (all UnrealIRCd 6 versions):

set {
        anti-flood {
                staff {
                        /* Allow more concurrent PM's */
                        max-concurrent-conversations {
                                users 10;
                                new-user-every 1s;
                        }
                        /* Allow users to flood 3 times faster than regular identified users */
                        lag-penalty 250;
                        lag-penalty-bytes 0;
                }
        }
}

Flood rates

In the example of above, we allow the security group staff to send a command every 250 milliseconds due to the lag-penalty 250; setting.

This means:

• 4 commands per second (1000/250=4)
• And bursting of 10000/250=40 commands (if, after such a burst, not sending higher than 4 commands per second).

If you need faster rates then here is a cheat sheet for the lag-penalty setting:

lag-penalty	Commands per second	Maximum burst of commands in 1 second
1000	1	10
250	4	40
100	10	100
50	20	200
25	40	400
10	100	1000

The above is the easy explanation. For exact details of lag-penalty and lag-penalty-bytes and the fake lag algorithm, see the set::anti-flood block but this is a fairly complex topic.

Exempting from server bans

You can exempt security groups from server bans (not channel bans) via the Except ban block:

except ban {
        mask { security-group staff; }
        type all;
}

The type all; will exempt them from *LINEs, SHUN, Spamfilter, but also give them unlimited maxperip.

If you feel like this is too much, then you can also choose to only exempt the group from certain types of server bans, see the Except ban block article on how to fine-tune this.

Allow and class block

You can create a class { } block with a higher sendq/recvq, like:

class staff {
        recvq 16k;
        sendq 1M;
        pingfreq 120;
        maxclients 128;
}

And then you need to create an allow { } block to put users with the security group staff in the class staff:

allow {
        mask { security-group staff; }
        class staff;
        maxperip 99;
}

IMPORTANT: This allow block must be placed BELOW your general allow block that has mask *;. So the general allow block with mask *; must come first, and then after that the allow block with mask { security-group staff; }.

Verifying it works

After rehashing the IRCd, let a user connect and use SASL to identify to their Services account.

When the user connects, you will see in the "Client connecting" server notice staff listed in the [security-groups: known-users,staff] portion.

If you want to verify the class { } a user is in, use TRACE Nickname

IMPORTANT: We assume you use a security-group with account here. If you do, then be sure to use SASL to identify to the services account. If you do not use SASL and use old fashioned NS IDENTIFY then the identifying takes place too late and the user will not be exempt from server bans like gline and will not be put in a special class. Some other settings still work (like set and set::anti-flood), but only work after the NS IDENTIFY. So, long story short: use SASL and not NS IDENTIFY!