View Issue Details

IDProjectCategoryView StatusLast Update
0001488unrealircdpublic2004-01-17 19:32
ReporterAngryWolf Assigned Tocodemastr 
Status resolvedResolutionfixed 
Summary0001488: Extban bug with is_ok
DescriptionI've just tested the new extended ban system and found a bug in it. It happens when I code my own is_ok function and use it in the ExtbanInfo structure (I know this part hasn't been tested yet) and IRC operators attempt to set an invalid ban mask that is_ok() doesn't allow. Actually the problem is that line 2305 in channel.c ignores the return value of is_ok if IsAnOper(cptr) is true. I'ld be glad to see that fixed.
TagsNo tags attached.
3rd party modules



2004-01-11 08:58

reporter   ~0004630

I've forgotten to fill in some fields. Just to be exact:

Unreal3.2 from devel CVS,
ReleaseID ( 2004/01/10 05:53:31).


2004-01-11 15:43

reporter   ~0004634

The is_ok is really to check access, not legality. Maybe an additional "type" should be created like EXBCHK_SYNTAX or something. That one would verify the syntax and it would not allow opers to bypass.


2004-01-11 20:05

administrator   ~0004643

You should just return NULL in the conv_param routine if the parameter is invalid.

In the extended _chanmode_ system we do have a EXCHK_PARAM, but adding that to is_ok for extbans AND having an conv_param seemed like doing duplicate work :).

Anyway, I think I didn't propperly document that indeed ;).


2004-01-11 20:31

reporter   ~0004648

I also thought of the conv_param routine, but unfortunately it doesn't allow me to return a message to the client in which I could describe why the parameter was invalid. Simply ignoring bad parameters are not always helpful (specifically for newbies, but I'm not talking only about them).


2004-01-11 20:36

administrator   ~0004649

hmm ic. It's how many modes work however, but...
I guess you could add EXBCHK_PARAM then.


2004-01-11 22:09

reporter   ~0004652

Yes, it would be fine if that was possible.


2004-01-17 19:32

reporter   ~0004710

EXBCHK_PARAM was added in .2047

Issue History

Date Modified Username Field Change
2004-01-11 08:51 AngryWolf New Issue
2004-01-11 08:58 AngryWolf Note Added: 0004630
2004-01-11 15:43 codemastr Note Added: 0004634
2004-01-11 20:05 syzop Note Added: 0004643
2004-01-11 20:31 AngryWolf Note Added: 0004648
2004-01-11 20:36 syzop Note Added: 0004649
2004-01-11 22:09 AngryWolf Note Added: 0004652
2004-01-12 13:00 syzop Severity major => minor
2004-01-12 13:00 syzop Status new => acknowledged
2004-01-12 13:00 syzop ETA none => < 1 month
2004-01-17 19:32 codemastr Status acknowledged => resolved
2004-01-17 19:32 codemastr Resolution open => fixed
2004-01-17 19:32 codemastr Assigned To => codemastr
2004-01-17 19:32 codemastr Note Added: 0004710