View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003257 | unreal | ircd | public | 2007-03-08 11:25 | 2015-05-27 18:30 |
| Reporter | CS-Help | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| OS | Linux | OS Version | 2.6.17 | ||
| Product Version | 3.2.6 | ||||
| Fixed in Version | 3.2.7 | ||||
| Summary | 0003257: Users can set +f mode multiple times | ||||
| Description | <18:45:41> * JanisB sets mode: +f [10j#i3,12m#m3,3t#b]:6 <18:45:43> * JanisB sets mode: +f [10j#i3,12m#m3,3t#b]:6 JanisB isn't services and mode setting is somehow throttled, but still possible. | ||||
| Steps To Reproduce | /mode #test +f [10j#i3,12m#m3,3t#b]:6 | ||||
| Additional Information | U:Lined clients like services can "flood" channels, like setting +nt on channel, that already has this modes. Regular users cannot set 2+ times same modes on same channel, except +f | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I cannot reproduce this on 3.2.6. [20:07:10] * Ein sets mode: +f [10j#i3,12m#m3,3t#b]:6 (and then more attempts, but nothing happens) You sure that JanisB isn't ulined? Anything else you could think of that could make me reproduce this? I tried both as normal user and as oper. |
|
|
Amazingly... Unreal3.2.6. irc.lv FhinXeOoZE [*=2309]... User is really user, because it's me and i am neither service, nor oper. I cannot re-set other modes, like +n, +n, +n e.t.c. JanisB has +ao on channel, but it still works with just +o. This server is not mine, but i know that owners wasn't modified any sources. P.S. Hm. Looks like this "bug" is only on one channel with 600+ ppls (Reconnects doesn't affect this). On other channels this mode can be set only once. Most probably it will disappear at next server restart. Sorry, `Reproducibility` must be "chaotic" :) |
|
|
well, it may be that the timestamp of the channel is messed up or something... |
|
|
Server was restarted, but i still can set +f +f on channel with 370+ ppl. |
|
|
Ok, i'll keep the bug open, will check it out another time :) Not too urgent though (but thanks for the report) ;p EDIT: +tnx |
|
|
funny: [12:54:39] -› Mode: (ChanServ) sets (+o Bock) [12:54:46] -› Modes in (#software): +ntrf [10j#R5,20m#M5,10n#N5,15t#b]:20 [12:54:46] -› Channel created on (Tuesday, February 21st 2006, 14:15:05) [12:54:58] -› Mode: (Bock) sets (+f [10j#R5,20m#M5,10n#N5,15t#b]:20) [12:55:07] -› Mode: (Bock) sets (-f [10j#R5,20m#M5,10n#N5,15t#b]:20) [12:55:08] -› Mode: (Bock) sets (+f [10j#R5,20m#M5,10n#N5,15t#b]:20) [12:55:38] -› Mode: (ChanServ) sets (+a Bock) [12:55:39] -› Mode: (Bock) sets (+f [10j#R5,20m#M5,10n#N5,15t#b]:20) [12:55:46] -› Mode: (ChanServ) sets (+q Bock) [12:55:53] -› Mode: (ChanServ) sets (-a Bock) [12:56:01] -› Mode: (ChanServ) sets (-q Bock) [12:56:03] -› Mode: (Bock) sets (+f [10j#R5,20m#M5,10n#N5,15t#b]:20) [12:56:07] -› Mode: (ChanServ) sets (+a Bock) After gives all modes I'll try to: /mode #software +f [10j#R5,20m#M5,10n#N5,15t#b]:20 Not in even cases it's permitted, but sometimes it's does. |
|
|
Found I think (or at least 1 cause): if (chptr->mode.floodprot && !memcmp(chptr->mode.floodprot, &newf, sizeof(ChanFloodProt))) break; /* They are identical */ it's comparing too much, including things like joincounters and such. Should be changed to a subfunction which compares: struct SChanFloodProt { unsigned short per; /* setting: per <XX> seconds */ <-- this time_t t[NUMFLD]; /* runtime: timers */ unsigned short c[NUMFLD]; /* runtime: counters */ unsigned short l[NUMFLD]; /* setting: limit */ <-- this unsigned char a[NUMFLD]; /* setting: action */ <-- this unsigned char r[NUMFLD]; /* setting: remove-after <this> minutes */ <-- this unsigned long timer_flags; /* if a "-m timer" is running this is & MODE_MODERATED etc.. */ }; the ones tagged by this and not the rest. Better yet, shift 't' and 'c' to the bottom and use one memcmp right until (but not including) timer_flags using offsetof() etc. Still done in a nice subfunc of course. [not working on it atm though] |
|
|
This has been fixed.. but when? Best guess is in 3.2.7. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-03-08 11:25 | CS-Help | New Issue | |
| 2007-03-08 13:10 | syzop | Note Added: 0013290 | |
| 2007-03-08 14:18 | CS-Help | Note Added: 0013291 | |
| 2007-03-08 14:19 | CS-Help | Note Edited: 0013291 | |
| 2007-03-08 20:05 | djGrrr | Note Added: 0013293 | |
| 2007-03-09 09:09 | CS-Help | Note Added: 0013294 | |
| 2007-03-09 10:59 | syzop | Note Added: 0013295 | |
| 2007-03-09 10:59 | syzop | Note Edited: 0013295 | |
| 2007-03-10 04:57 | Bock | Note Added: 0013299 | |
| 2007-03-10 05:43 | syzop | Note Added: 0013301 | |
| 2007-03-10 05:43 | syzop | Status | new => confirmed |
| 2015-05-27 18:30 | syzop | Note Added: 0018365 | |
| 2015-05-27 18:30 | syzop | Status | confirmed => resolved |
| 2015-05-27 18:30 | syzop | Fixed in Version | => 3.2.7 |
| 2015-05-27 18:30 | syzop | Resolution | open => fixed |
| 2015-05-27 18:30 | syzop | Assigned To | => syzop |
