View Issue Details

IDProjectCategoryView StatusLast Update
0003257unrealircdpublic2015-05-27 18:30
ReporterCS-Help Assigned Tosyzop  
Status resolvedResolutionfixed 
OSLinuxOS Version2.6.17 
Product Version3.2.6 
Fixed in Version3.2.7 
Summary0003257: 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 InformationU: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
TagsNo tags attached.
3rd party modules



2007-03-08 13:10

administrator   ~0013290

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.


2007-03-08 14:18

reporter   ~0013291

Last edited: 2007-03-08 14:19

Amazingly... Unreal3.2.6. 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" :)


2007-03-08 20:05

reporter   ~0013293

well, it may be that the timestamp of the channel is messed up or something...


2007-03-09 09:09

reporter   ~0013294

Server was restarted, but i still can set +f +f on channel with 370+ ppl.


2007-03-09 10:59

administrator   ~0013295

Last edited: 2007-03-09 10:59

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


2007-03-10 04:57

reporter   ~0013299


[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.


2007-03-10 05:43

administrator   ~0013301

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]


2015-05-27 18:30

administrator   ~0018365

This has been fixed.. but when? Best guess is in 3.2.7.

Issue History

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