View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0006590unrealircdpublic2025-11-06 23:012025-11-08 15:17
Reporterwestid Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version6.2.1 
Summary0006590: security group rules priority
Descriptionwhen you're in more than one security group with maxchannelsperuser, it only gives you the minimum number of channels in that group

so if you're in known-users registered-users and high-reputation, and:
set known-users {
    max-channels-per-user 10;
}

set high-reputation {
    max-channels-per-user 15;
}

set registered-users {
    max-channels-per-user 20;
}

how do you select which group's rules takes precedence? if you have earned/been given more max channels, and qualify for three groups it picks the lowest - but all three of these groups are true for a registered user
TagsNo tags attached.
3rd party modules

Activities

Valware

2025-11-07 00:36

reporter   ~0023536

Hey there. Thanks for your bug report.

I know my solution perhaps sounds a bit overly complicated, but I would advise to take a look at making some security-groups which make use of [code]security-group { }[/code] and [code]exclude-security-group { }[/code] to fine-tune things. You can use this to make categories based on what security-groups a user is and is not in and apply maxchannelsperuser to those parent security-groups.

[code]
security-group max-chans-ten {
  security-group {
    known-users;
  }
  exclude-security-group {
    high-reputation;
  }
  // And so on
}
[/code]

Hope this helps!
https://www.unrealircd.org/docs/Security-group_block#Syntax

syzop

2025-11-07 08:41

administrator   ~0023537

i edited your post a little, since i presume you mean the dynamic set items (well, it can't be anything else), so just to illustrate :D

syzop

2025-11-07 08:46

administrator   ~0023538

Last edited: 2025-11-07 08:49

 (Added example of problem in previous post)

At the moment we walk through each of the security groups, then if the user matches that group and there is a dynamic set item for it, the first match wins. So processing stops on first match. There is an undocumented feature, security-group::priority, by which could assign which security group is most important / wins. A higher priority wins here. And then it is good to know that known-users has priority 100. So you could make your high-reputation group priority 1000 and the registered-users group priority 2000, if that is the order of importance for you.

Does that work for you?

syzop

2025-11-07 16:40

administrator   ~0023539

I have documented security-group::priority at https://www.unrealircd.org/docs/Security-group_block
Have also updated the pages that refer to this or contain examples:
https://www.unrealircd.org/docs/Set_block#Set_block_for_a_security_group
https://www.unrealircd.org/docs/Anti-flood_settings#Introduction_and_default_settings
https://www.unrealircd.org/docs/Special_users#Define_a_security_group

westid

2025-11-07 23:53

reporter   ~0023540

these answers are brilliant thank you very much

westid

2025-11-08 03:05

reporter   ~0023541

i have been playing around with this for a while, and i could be wrong, but the security group with the lowest number appears to be prioritised first [this is 6.2.1]

westid

2025-11-08 03:11

reporter   ~0023542

i did a simple thing combining both of your techniques

if channel owners set +L # ...

/* INCORRIGO SYX IRC NETWORK
 *
 * This is the security group block. It doesn't replace the default
 * security groups in the unrealircd configuration. */

security-group registered {
    priority 70;
    identified yes;
    account *;
    exclude-security-group spam-fool;
}

/* strange behaviour */
security-group popup {
    mask *.amazonaws.com;
}

security-group well-known-users {
    priority 80;
    security-group known-users;
    reputation-score 1969;
    exclude-security-group spam-fool;
}

security-group spam-fool {
    priority 40;

    channel {
        "#";
    }
}

security-group unregistered {
    priority 75;
    mask *;
    exclude-identified yes;
    exclude-account *;
    exclude-security-group spam-fool;
}

security-group plaintext {
    priority 65;
    mask *;
    exclude-tls yes;
    exclude-security-group spam-fool;
}

security-group operator {
    priority 19;
    rule "is_tls() && has_user_mode('o')";
}

security-group network-admin {
    /* accounts are secure enough already */
    priority 13;

    account {
        ...
    }
}

set popup {
    auto-join "#bot";
}


security-group webirc {
    webirc yes;
}

set operator {
    max-channels-per-user 29;
}

set registered {
    max-channels-per-user 17;
}

set plaintext {
    maxchannelsperuser 4;
    static-quit "goodbye. [plaintext session ended]";
    static-part yes;
}

set well-known-users {
    max-channels-per-user 10;
}

set unknown-users {
    max-channels-per-user 5;
}

set unregistered {
    max-channels-per-user 7;
}

set network-admin {
    max-channels-per-user 99;
}

westid

2025-11-08 03:16

reporter   ~0023543

set spam-fool {
    max-channels-per-user 1;
}

syzop

2025-11-08 10:28

administrator   ~0023544

That could be true. So everything works now with the lower priority thingy? I don't have time right now but can adjust the documentation later.

westid

2025-11-08 10:51

reporter   ~0023545

i've tested it with max-channels-per-user and nick flood and yeah the lowest priority seems to hit first when user belongs to more than one security group

syzop

2025-11-08 15:17

administrator   ~0023546

Thanks! I've adjusted the documentation.

Issue History

Date Modified Username Field Change
2025-11-06 23:01 westid New Issue
2025-11-07 00:36 Valware Note Added: 0023536
2025-11-07 08:40 syzop Description Updated
2025-11-07 08:40 syzop Description Updated
2025-11-07 08:41 syzop Note Added: 0023537
2025-11-07 08:46 syzop Note Added: 0023538
2025-11-07 08:47 syzop Priority high => normal
2025-11-07 08:47 syzop Severity major => minor
2025-11-07 08:49 syzop Note Edited: 0023538
2025-11-07 16:40 syzop Note Added: 0023539
2025-11-07 23:53 westid Note Added: 0023540
2025-11-08 03:05 westid Note Added: 0023541
2025-11-08 03:11 westid Note Added: 0023542
2025-11-08 03:16 westid Note Added: 0023543
2025-11-08 10:28 syzop Note Added: 0023544
2025-11-08 10:51 westid Note Added: 0023545
2025-11-08 15:17 syzop Assigned To => syzop
2025-11-08 15:17 syzop Status new => resolved
2025-11-08 15:17 syzop Resolution open => fixed
2025-11-08 15:17 syzop Note Added: 0023546