View Issue Details

IDProjectCategoryView StatusLast Update
0003193unrealircdpublic2010-08-14 20:42
ReporterShining PhoenixAssigned Toaquanight 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Platformi386OSLinuxOS Version2.6.10-1.771_FC2
Product Version3.2.6 
Target VersionFixed in Version3.2.9-RC1 
Summary0003193: Enable some combinations of extbans
DescriptionExtbans ~c and ~r are different ways of specifying users, ~n and ~q are different things to do to users. Some new combos could be:
~nc - Users in matching channel can('t) nickchange
~nr - Users with matching realname can('t) nickchange
~qc - Users in matching channel can('t) speak
~qr - Users with matching realname can('t) speak
And if the new simple ewxtban I suggested was added:
~jc - Users in matching channel can('t) join
~jr - Users with matching realname can('t) join

Nice, accurate little extbans. I think anyone who uses ~c and ~r extbans may use these as well :)
TagsNo tags attached.
3rd party modules

Relationships

related to 0003928 resolvedsyzop Fix chained/stacked bans 
child of 0003284 acknowledged 3rd Party Module Wishlist 

Activities

Stealth

2007-01-06 11:54

reporter   ~0013008

That'd be nice

Bricker

2007-01-06 21:28

reporter   ~0013020

this seems way over the top. imo write a module for it, i wouldnt stick it in the core

Shining Phoenix

2007-01-07 00:55

reporter   ~0013022

Yeah, but we know how 3rd party modules cause problems =P
I guess I could request a module for this
/me wanders off to the forums

aquanight

2007-01-08 13:42

reporter   ~0013032

Last edited: 2007-01-08 13:45

I'd think it's a bit simpler to just do "chained" extbans. Basically as it is now, ~n and ~q just take a n!u@h mask, but we could just pass the mask right back to the ban parser, thus allowing something like:

+b ~n:~c:#blah - anyone in #blah can't /nick
+b ~q:~r:*lamer* - anyone with "lamer" in realname can't speak

Note you wouldn't be able to do this the other way around: for example, ~c:~q:#blah wouldn't work.

This could conceivably be done to any extban that would otherwise just take a normal n!u@h mask.

Of course you could then do wierd but useless combinations like ~q:~n:~q:~n:~q:~q:~n:~n:~c:#blah(*) ... but not for me to tell people not to uselessly waste banspace if they really want to do that for some reason.

Bricker:
As it is now, you can't write a module for it - extbans are only allowed one character (another reason why "chaining" as stated above would work better), and you can't "override" extbans like you do commands. Also it wouldn't allow extending this to other extbans, like RegExcept, etc. And if you look at the extban.c code for ~q/~n - it's a change of exactly 1 function call for each of the two (from extban_is_banned_helper to just is_banned) so it's not a stupidly complicated change or anything.

(
(*) == Useless because ~q:blah == match (blah) only during msg check, and ~n:blah == match (blah) only during nick change, so ~q:~n:blah == match (match (blah) only during nick change) only during msg check == can never match.
)

[edit: I should also point out that a chained ban would likely also not work with extban that doesn't ban on the join/nick/msg basis (eg: syzop's textban module). Also I suppose it would be necessary for ~q/~n's "format convparam to forward to the sub-extban's convparam]

Shining Phoenix

2007-01-21 22:58

reporter   ~0013077

Last edited: 2007-01-23 21:19

*Ignore this suggested syntax, look at the next one*

Hmm, I have an idea. What if a user could only set one mode at a time when using an extban? So, when the first parameter after the mode has a ~ in front:

/mode #channel {+|-}<mode> ~<extbans> {extbanparam} {extbanparam} ... {n!u@h}

And when the first parameter after the mode does not have a ~ in front, it is handled normally. That way, you could combine any number of extbans together, e.g.

/mode #channel +b ~jr stupid_bot_script *!*@*.aol.com

Stealth

2007-01-22 13:47

reporter   ~0013091

The problem with that, is all the extban params need to be in 1 ban param. Spaces separate params, so it would not work.

Shining Phoenix

2007-01-23 02:42

reporter   ~0013092

Umm, read over my suggestion more closely. When someone sets an extban using this system, they can only set one ban mode at a time. Then, since there are no other mode parameters to confuse things, the extban parameters can be seperated by spaces.

aquanight

2007-01-23 09:37

reporter   ~0013097

No.

- It would most certainly break clients. Much more than extbans do already.
- It's extra work for the mode parser when simpler solutions are available.

Shining Phoenix

2007-01-23 21:08

reporter   ~0013098

Last edited: 2007-01-29 23:13

*I keep coming up with new ideas, look further down*
Hmm.
mode # +b/e/I ~type1:param1:param2:~type2:param3:param4
So, "after the second colon, before the next :~" would be the definition of param2 in that, then having : within an extban param(e.g. IPv6), and having ~ in an extban param(e.g. ~#chan2) wouldn't be a problem.
I'm fairly sure no extban parameter would have ~: in it.

tabrisnet

2007-01-23 21:11

reporter   ~0013099

a) ~T or ~r could contain _any_ characters
b) I back aquanight on this one.

tabrisnet

2007-01-23 21:12

reporter   ~0013100

a) chaining ~n and ~q to the extbans sounds interesting.
b) adding multiple parameters is a bit much, and likely impossible.

Shining Phoenix

2007-01-23 21:17

reporter   ~0013101

Last edited: 2007-01-29 23:14

Tabrisnet said:
a) ~T or ~r could contain _any_ characters

Hmm.
1. Don't allow a combo of T and/or r and/or c and/or f
2. Make sure their troublesome parameter is specified last.

Then, the banned text would be "all the stuff after the colon after the ~T:", the banned realname would be "all the stuff after the ~r:", the banned channel would be "all the stuff after the ~c:", and the forwarded channel would be "all the stuff after the ~f:".

...that just disallowed nearly every combo there is...

Or, only allow combos between any number of action extbans, and just one usermatching extban. e.g.

~nq:n!u@h
~jr:realname
~qc:@#lamers
~nqfC:#losers:202.156.345.765/32 <--usermatching param is all after last colon

*More detail below*

aquanight

2007-01-23 22:02

reporter   ~0013102

Last edited: 2007-01-23 22:10

The rule has always been 1 mode has no more than 1 parameter. Only +f and +j break this rule, but they need to. +b does not need to because it's a list mode. People can take the time to do +bbbbbbbbbbbbeIeIo blah....

Also, ~c bans *CAN* start with a tilde. You can use a PREFIX= prefix to match users in the channel with that status or higher. ~r can start with tildes. ~T can start with tildes. If you start saying X ban type has to be last (and you can't core-side enforce that for ~T, it's module-provided, so now you have to somehow let the module say "has to be last"), you completely defeat the purpose of the whole thing. This is exactly why it should stay one extban per +b, no more. Plus now you have to parse something around something other than a space seperator. Basic IRC already takes care of parameters as it is, no need for +b to do extra logic. (Checking for ~, some letter, and : is easy enough, but having to strtok() loop over a :-seperated list is pushing it.) And what is the benefit of it anyway? You don't get any more or less banspace with it (banspace is limited by # of bans and by raw length), and it's simpler to do +bbbb ban1 ban2 ban3 ban4 (and some clients have a command to do it for you, and some might even break it up into multiple /modes if you go over 12 bans).

Extended bans confuse clients enough since they know only of normal bans. Please let's *NOT* confuse them anymore with multiple parameter stuff. One mode, one parameter. It's worked so far, why break it?

It's feasible to chain ~q: and ~n: (and ~j:) onto the other extbans. It's just taking the fact that they already do half the work of normal ban parsing (normal n!u@h), and changing *one* function call (and add forwarding logic in convparam) is enough to have the other half. It isn't feasible to go wild with it and start chaining X00 bans onto the one entry.

[edit: Ick, looks like I was wrong: is_banned is what actually checks the entire banlist (not just one ban). But we could extract the check of the individual ban inside the loop into a function and then just use that.]

Shining Phoenix

2007-01-23 23:12

reporter   ~0013103

Last edited: 2007-05-07 20:28

Hmm. Make ban syntax(I know this is a clumsy way to show it):

mode #chan {+|-}<b|e> {~<{action}{masktype}|{other}:>}<mask>

All extbans would be either action, masktype or other. Put all extbans in modules perhaps?

Where action currently is = j|n|q|jn|nq|jq

Masktype currently is = C|E|r|c

Other currently is = T

{optional}
<required>
option1|option2

Bricker

2007-01-27 17:04

reporter   ~0013127

jesus H christ! FIX IT ALREADY! ;P

Shining Phoenix

2007-01-31 03:23

reporter   ~0013156

Last edited: 2007-01-31 03:24

aquanight said:
I'd think it's a bit simpler to just do "chained" extbans. Basically as it is now, ~n and ~q just take a n!u@h mask, but we could just pass the mask right back to the ban parser, thus allowing something like:

+b ~n:~c:#blah - anyone in #blah can't /nick

I say:
Would +b ~n:~c:~#blah work?

JasonTik

2007-02-01 18:12

reporter   ~0013157

Last edited: 2007-02-01 18:13

This conversation is getting weird. I agree with aquanight. The ~q:~c:#Chan chaining stuff is the way to go.

Also: A ~j: would be very nice. As it is, a normal ban is ~j & ~q

Shining Phoenix

2007-02-01 20:34

reporter   ~0013158

Err, a normal ban is ~q, ~j and % or higher required to nickchange >.>

Well, if you're sure about the chaining, ok. A lot of ~: to type =(

Shining Phoenix

2007-05-07 20:33

reporter   ~0014028

*bump*

Chained extbans would be a good feature, e.g.
+b ~n:~c:~#lame_guys_channel

Modules that provide extra extbans would need to be fixed afterwards to take advantage of this feature...especially m_hostforward (extban ~f).

Disallowing colons in channel names, which I believe is going to be done in future, will make chained extbans more doable.

syzop

2007-05-08 04:24

administrator   ~0014045

aquanight wanted to do this but, basically I said waaaaah waittt ;P

But I'd be fine if you (aquanight) would again look into it... with a few remarks:
* Things should stay very fast, ban checking is one of the most important CPU eating tasks in the IRCd (top 5).
* The code shouldn't be cluttered too much, aka "try to keep the code nice"
* There should be a config option to disable this feature (for speed/personal preferences/etc)
* Should only allow one combination like ~q:~c:#chan and not like ~q:~c:~c and such ;p
* You're right, be careful with allowing which extbans to be extended, sometimes ~ may be used in the extban itself already, so that means it could not be extended or else you get confusion. I guess extbans should somehow set a flag (on init/load/whatever, in the extbanadd thing) whether they'd allow them to be extended or not. ~q and ~n look a good place to start.


So like point 1 (speed), if you'd split things to 'check whole banlist' and 'check individual ban' functions, be sure to tag the 2nd as inline, and.. also use the n!u@h buffers (std, ip, cloak, etc) in that function and don't go rebuild them for every ban... you get the idea.

well, you probably get a good idea how to do things then, have fun ;P

*****

Then on ~j.. that deserves a separate report, with some good explanation over there why it would be useful.

Shining Phoenix

2007-05-10 21:54

reporter   ~0014083

~j at http://bugs.unrealircd.org/view.php?id=3192

aquanight

2007-05-12 10:05

reporter   ~0014096

Going with the chained extban deal. To sum up what's basically going to happen:
- Any extban (like, say, ~q) that normally uses (as either all or part of their parameter) a nick!user@host mask, can instead choose to allow sticking an extban in its place. So eg for ~q:nick!user@host, you could then do ~q:~c:#stfu.
- It will be up to each extban to decide if it wishes to allow stacking extbans or not. The current extban_is_banned_helper() function that allows extbans to easily do n!u@h matching will remain as it is (= no extban stacking) for compatibility.
- An extban that wishes to allow stacking will call a function like ban_check_mask, which will do n!u@h, or extban, as appropriate. Such extbans also need to arrange for convparam forwarding.
- Since extbans are in control of whether or not extbans stack, they are given responsibility for dealing with any stacking limits they might want to impose, or to, say, collapse wasteful things like ~q:~q:~q:~q:~q:blah, to ~q:blah.
- I'm still considering whether to control this behavior with a ./Config option or unrealircd.conf option, or indeed if such an option is really needed at all. I can understand the whole "personal preferences" deal though, and I'm leaning toward ./Config option since that way will ensure modules have to respect it (as if they don't, they won't compile when support for it is switched off :P ).

aquanight

2007-05-13 17:19

reporter   ~0014121

Added to devel (3.3*) CVS, .2397

I'll do a slightly better write-up or something when I have time. Put simply, though, existing modules don't have to change unless they want to deal with chained extbans, but core extbans now support chaining. For compatibility, an Config option disables this support, and makes extbans work pretty much exactly as it did before. (So basically, modules can still support this and be ok in 3.2 because of the #define.)

- Added support for "chained" extbans. Put simply this allows extban combinations
  such as ~q:~c:#test to only silence users on #test, for example. This feature
  is enabled by default, but can be disabled during ./Config -advanced. Module
  support for this feature must note the following:
  - For is_ok function, the extban can either assign extban_is_ok_nuh_extban, which
    will deal checking a chained extban (including checking for restricted extbans),
    or it can call that function from its own is_ok routine. For the latter case,
    remember to pass only the mask part of your ban format (ie, don't just pass para as
    otherwise it'll just call your is_ok again).
  - For conv_param function, the extban can either assign extban_conv_param_nuh_or_extban,
    which will automatically call conv_param for a chained extban, or pretty up a n!u@h mask.
  - For is_banned, the extban should call ban_check_mask with the mask part of the parameter.
    This will automatically call is_banned for a stacked extban, or match against a n!u@h. n!u@h
    is checked against the current user (ie, with the info in the globals ban_ip, etc), so things
    can get weird if you call this outside a normal ban check.
  Modules must keep in mind that chained extban support is not available (and neither are the three
  functions above) if DISABLE_STACKED_EXTBANS is #defined (this is controled by Config). Modules will
  not compile/load if they try to use them anyway.
  This change should not break extban modules, and should need some more extensive testing.

Shining Phoenix

2008-09-03 04:21

reporter   ~0015399

The problem with combining extbans is that if you can combine some but not others, then you have to remember which can and can't be combined, which makes it more complex. If any extbans could be combined in one ban, then this topic gets simpler. If there was one magic character that could seperate the parameters of each extension, then you could do +b ~thing1:~thing2:param1<magic character>param2
An analogy for this is that the magic character in mode lines is a space, ie /mode #channel mode1mode2 thing1 thing2
The sticking point here is that I couldn't think of a suitable magic character for seperating the parameters of a chained ban.
Today I think I figured it out.
<magic character> is a semicolon
As far as I know, semicolons are never in the host part of nick!ident@host, nicknames, CIDR bans or server names. So all that's left to worry about are channel names and real names. If semicolons are disallowed in channel names and real names, then semicolon won't be used within the matching bit of any extban (except T, I'll get to that later), so it can be used as the magic character.
To diallow semicolons in real names, I suggest that ; gets changed to T, so that if a person has ;-; in their real name it changes to T.T, hence retaining its original meaning.
Chaning textban ~T with other extbans is doomed to fail, so it simply shouldn't be allowed. So yeah, people would need to remember that T doesn't chain, but that's easier to remember than "c, C and r (and s if unreal has it) don't chain with each other".

syzop

2010-08-14 20:41

administrator   ~0016271

Added in CVS mass-commit .863:
- This is actually an update of earlier code from CVS, but now it works ok:
- Added support for "stacked" extbans. Put simply this allows extban combinations
  such as ~q:~c:#test to only silence users on #test, for example. This feature
  is enabled by default, but can be disabled during ./Config -advanced.
  This feature was suggested by Shining Phoenix (0003193), was then coded
  by aquanight for U3.3, and later on backported and partially redone by Syzop.
  Module coders:
  In an extban ~x:~y:something where we call ~x the 1st, and ~y the 2nd extban:
  Since stacked extbans only makes sense where the 1st one is an action
  extended ban like ~q/~n/~j, most modules won't have to be changed, as
  their extban never gets extended (just like ~c:~q: makes no sense).
  However, you may still want to indicate in some cases that the extban your
  module introduces also shouldn't be used as 2nd extban.
  For example with a textban extban ~T it makes no sense to have ~n:~T.
  The module can indicate this by setting EXTBOPT_NOSTACKCHILD in
  the ExtbanInfo struct used by ExtbanAdd().
  For completeness I note that action modifier extbans are indicated by
  EXTBOPT_ACTMODIFIER. However, note that we currently assume all such
  extbans use the extban_is_ok_nuh_extban and extban_conv_param_nuh_or_extban
  functions. If you don't use these and use EXTBOPT_ACTMODIFIER, then things
  will go wrong with regards to stack-counting.
  Module coders should also note that stacked extbans are not available if
  DISABLE_STACKED_EXTBANS is defined.
- Added extended ban ~R:<nick>, which only matches if <nick> is a registered
  user (has identified to services). This is really only useful in ban
  exemptions, like: +e ~R:Nick would allow Nick to go through all bans if he
  has identified to NickServ. This is often safer than using +e n!u@h.
- Added Extended Invex. This is very much like extended bans, in fact it
  supports some of the same flags. Syntax: +I ~character:mask
  Currently supported are: ~c (channel), ~r (realname) and ~R (registered).
  This can be useful when setting a channel invite only (+i) and then
  setting invite exceptions such as +I ~c:#chan (or even ~c:+#chan), while
  still being able to ban users.
  Because action modifiers (~q/~n/~j) make no sense here, extended invex
  stacking (+I ~a:~b:c) makes no sense either, and is not supported.
  Suggested by DanPMK (0002817), parts based on patch from ohnobinki.
  Module coders: set EXTBOPT_INVEX in the ExtbanInfo struct used by
  ExtbanAdd() to indicate that your extban may also be used in +I.
- Invex (+I) now always checks cloaked hosts as well. Just like with bans,
  it checks them also when the user is not currently cloaked (eg: did -x, or
  is currently using some VHOST).
- Fixed client desynch caused by (un)banning, reported by Sephiroth (#2837).

Issue History

Date Modified Username Field Change
2007-01-06 06:13 Shining Phoenix New Issue
2007-01-06 11:54 Stealth Note Added: 0013008
2007-01-06 21:28 Bricker Note Added: 0013020
2007-01-07 00:55 Shining Phoenix Note Added: 0013022
2007-01-08 13:42 aquanight Note Added: 0013032
2007-01-08 13:45 aquanight Note Edited: 0013032
2007-01-21 22:58 Shining Phoenix Note Added: 0013077
2007-01-22 13:47 Stealth Note Added: 0013091
2007-01-23 02:42 Shining Phoenix Note Added: 0013092
2007-01-23 09:37 aquanight Note Added: 0013097
2007-01-23 21:08 Shining Phoenix Note Added: 0013098
2007-01-23 21:11 tabrisnet Note Added: 0013099
2007-01-23 21:12 tabrisnet Note Added: 0013100
2007-01-23 21:17 Shining Phoenix Note Added: 0013101
2007-01-23 21:19 Shining Phoenix Note Edited: 0013077
2007-01-23 21:34 Shining Phoenix Note Edited: 0013101
2007-01-23 21:46 Shining Phoenix Note Edited: 0013101
2007-01-23 21:48 Shining Phoenix Note Edited: 0013101
2007-01-23 22:02 aquanight Note Added: 0013102
2007-01-23 22:10 aquanight Note Edited: 0013102
2007-01-23 23:12 Shining Phoenix Note Added: 0013103
2007-01-23 23:17 Shining Phoenix Note Edited: 0013103
2007-01-27 17:04 Bricker Note Added: 0013127
2007-01-28 01:35 Shining Phoenix Note Edited: 0013103
2007-01-29 23:13 Shining Phoenix Note Edited: 0013098
2007-01-29 23:14 Shining Phoenix Note Edited: 0013101
2007-01-29 23:19 Shining Phoenix Note Edited: 0013103
2007-01-31 03:23 Shining Phoenix Note Added: 0013156
2007-01-31 03:24 Shining Phoenix Note Edited: 0013156
2007-02-01 18:12 JasonTik Note Added: 0013157
2007-02-01 18:13 JasonTik Note Edited: 0013157
2007-02-01 20:34 Shining Phoenix Note Added: 0013158
2007-04-18 05:54 stskeeps Relationship added child of 0003284
2007-04-18 06:07 stskeeps Status new => acknowledged
2007-05-07 20:28 Shining Phoenix Note Edited: 0013103
2007-05-07 20:33 Shining Phoenix Note Added: 0014028
2007-05-08 04:24 syzop Note Added: 0014045
2007-05-10 21:54 Shining Phoenix Note Added: 0014083
2007-05-12 10:05 aquanight Note Added: 0014096
2007-05-12 10:05 aquanight Assigned To => aquanight
2007-05-12 10:05 aquanight Severity minor => feature
2007-05-12 10:05 aquanight Status acknowledged => assigned
2007-05-13 17:19 aquanight Note Added: 0014121
2007-05-13 17:19 aquanight Status assigned => resolved
2007-05-13 17:19 aquanight Resolution open => fixed
2007-05-13 17:19 aquanight Fixed in Version => 3.3-alpha0
2008-09-03 04:21 Shining Phoenix Status resolved => feedback
2008-09-03 04:21 Shining Phoenix Resolution fixed => reopened
2008-09-03 04:21 Shining Phoenix Note Added: 0015399
2010-07-14 21:16 syzop Relationship added related to 0003928
2010-08-14 20:41 syzop QA => Not touched yet by developer
2010-08-14 20:41 syzop U4: Need for upstream patch => No need for upstream InspIRCd patch
2010-08-14 20:41 syzop Note Added: 0016271
2010-08-14 20:41 syzop Status feedback => resolved
2010-08-14 20:41 syzop Fixed in Version 3.3-alpha0 => 3.2.9-RC1
2010-08-14 20:41 syzop Resolution reopened => fixed