IRC Advanced Privilege Control Model

The IRC Advanced Privilege Control Model is the permissions control model created by members of the IRCv3 working group for IRCv3 IRC daemons. It replaces the permissions model used by traditional IRCds.

Overview

A few IRCd projects involved in the IRCv3 working group decided that a new permissions model was needed. This permissions model was implemented in Charybdis 3.0 and InspIRCd 1.2. The full permissions model is still a work in progress, but covers:

• Privilege set declaration
• Privilege set transition (such as from 'user' role to 'ircop' role or 'admin' role) via:
  • /OPER command
  • /CHALLENGE command (charybdis extension)
  • Connection class
• Naming suggestions for common permissions and namespaces

Additional privilege set transition methods are planned, such as:

• Targeted SASL authentication result (IRCv3.2 proposal)
• CERTFP (planned inspircd extension)

Other eventual goals include describing RFC1459 user permissions and state/role transitions as a function of IAPCM configuration.

Additionally both Atheme 6 and Anope 1.9 implement the basis of the IAPCM standard with the following role transitions (but with different permissions schemes):

• NickServ IDENTIFY command
• IRC role transitions with fallback to usermode +o/+a detection
• OperServ IDENTIFY command
• X.509 fingerprint verification (CERTFP) result
• SASL authentication result (Atheme only)

Glossary of terms

Simple terms:

• privset, operclass, opertype, class, Privilege set: a congruent set of privileges and other rights
• oper, operator, Services operator, IRC operator: a user who has either operator status on services or the irc network itself

More bizarre terms:

• auspex: user which can view private information (from Latin auspex/auspice/auspices; "bird watcher". one which interprets the actions of birds for divination purposes)

Example (Charybdis-family IRCds)

This example assumes Charybdis-style config syntax, InspIRCd config syntax will be different, but similar (mainly XML-like).

First, we should declare some roles to transition into.

privset "ircop" {
    flags = oper:kill, oper:local_kill, oper:rehash, oper:override;
};
   
privset "admin" {
    inherits = "ircop";
    flags = oper:die, oper:restart;
};

Now declare some actual role transitions:

operator "Somebody" {
    password = "testing123";
    privset = "admin";
    flags = ~encrypted;  /* indicate to the ircd that the password is plaintext. */
};

If a user transitions into the admin role, she will also receive the permissions of the ircop role because of `privset::inherits`.

Example (InspIRCd)

This example assumes InspIRCd-style config syntax. If you are running a fork, the syntax may be different. Note that InspIRCd has some additional policy extensions available.

<class name="MassMessage"
       privs="users/mass-message">

<class name="Restart"
       privs="users/auspex channels/auspex"
       commands="DIE RESTART"
       inherits="ircop"
       usermodes="*" chanmodes="*">

Now declare some roles to transition into:

<type name="NetAdmin"
      classes="MassMessage Restart">

<type name="Helper"
      classes="MassMessage">

And some opers so that role transitions from the user role are available:

<oper name="SomePerson"
      password="testing123"
      type="NetAdmin">

Example (Atheme 6.0/Atheme 7.0)

This example assumes Atheme-style config syntax. Anope config syntax may differ.

As in the other examples, we first declare some roles:

operclass "admin" {
    extends ircop;
    
    privs {
        user:regnolimit;
        general:admin;
    };
    
    needoper;
};

The needoper keyword disallows a role transition into this role without having IRC operator status.

Now, declare some transitions:

operator "Somebody" {
    operclass = "sra";
};

Note: Atheme 7.1 is planning to add additional policy features, allowing for more complex policies. These extensions are not part of the IPACM 1.0 specification, but may become part of IPACM 2.

Example (Anope 1.9)

opertype {
    name = "helper"
    privs = "chanserv/auspex nickserv/auspex"
}

opertype {
    name = "admin"
    inherits = "helper"
    commands = "chanserv/* nickserv/* operserv/*"
    privs = "chanserv/auspex"
}

This declares two oper types, helper and admin. Now we need to define some role transitions.

oper {
   name = "moocow"
   type = "admin"
   require_oper = yes
}

oper {
   name = "otherguy"
   type = "helper"
}

This creates two role transition rules, which get expanded into a pseudo-ruleset as follows:

• If accountname is "moocow", and
  • The user logged into this account has IRCop status
  • The user's role will transition to "admin"

• If accountname is "otherguy", then the user logged into the account "otherguy" will transition to the "helper" role.

See Also

• IRCd Comparison (including a list of IRCds implementing the IRC Advanced Privilege Control Model).