View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001488 | unreal | ircd | public | 2004-01-11 08:51 | 2004-01-17 19:32 |
| Reporter | AngryWolf | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0001488: Extban bug with is_ok | ||||
| Description | I'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. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I've forgotten to fill in some fields. Just to be exact: Linux, Unreal3.2 from devel CVS, ReleaseID (1.1.1.1.2.1.2.1.2.2039 2004/01/10 05:53:31). |
|
|
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. |
|
|
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 ;). |
|
|
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). |
|
|
hmm ic. It's how many modes work however, but... I guess you could add EXBCHK_PARAM then. |
|
|
Yes, it would be fine if that was possible. |
|
|
EXBCHK_PARAM was added in .2047 |
| 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 |
|
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 |
|
Status | acknowledged => resolved |
| 2004-01-17 19:32 |
|
Resolution | open => fixed |
| 2004-01-17 19:32 |
|
Assigned To | => codemastr |
| 2004-01-17 19:32 |
|
Note Added: 0004710 |
