View Issue Details

IDProjectCategoryView StatusLast Update
0001640Anope Stable (2.0.x series)Generalpublic2015-03-23 14:00
Reporterazander Assigned ToAdam  
Status resolvedResolutionfixed 
Summary0001640: Channel giving ops when it shouldn't
DescriptionSet up a new channel, assign a bot, leave, then another user joins.
Similar issue, but without bot.

Did a /cs info #channel all which is in the log
Steps To ReproduceSteps:
 * Register nick (tester1 in attached logs)
 * Register Channel (#test5 in attached logs)
 * Assign bot (Bot in attached logs)
 * Leave channel
 * have another user join (tester2 in attached logs)
 -- Expected: Bot deops second user (tester2)
 -- Actual: Bot doesn't deop user (tester2)

Similar without bot, except ChanServ does not deop user.

Additional InformationThis has been tested with secureops on, and it works as expected when secureops is on.

TagsNo tags attached.



2015-03-23 14:00

administrator   ~0006724

fixed in 303e652a3563c50d8836996851341840b1ad4277


2015-03-12 19:00

administrator   ~0006722

This is from the keepmodes setting setting REGISTERED and conflicting with chanserv.cpp's take_modes registered check.


2015-03-12 02:23

developer   ~0006712

Configs from test server uploaded as requested. Only change to them is to remove passwords, except throw-away link password that doesn't matter.


2015-03-12 02:20


configs.tar.bz2 (35,809 bytes)


2015-03-11 16:26

administrator   ~0006710

I cannot reproduce this on a stock install of Unreal 3.2 latest and 2.0 git. Upload all of your configuration files.


2015-03-11 03:42

developer   ~0006709

For whatever reason, it is not deoping the user at all. It should.

Same results on another network using anope-2.0.x as well. IRCD & Services on the same machine. Both running Unreal, current version. Do you need any additional info?


2015-03-11 03:11

administrator   ~0006708

The intended behavior is that services (or maybe the server due to the TS lowering) will deop the first user who joins the channel if they do not have access, regardless of secure or secureops.


2015-03-11 03:01

reporter   ~0006707

I tested it, I followed your steps and ChanServ/BotServ deops the user...


2015-03-10 18:46

developer   ~0006706

This is not expected results.

Anope 1.8 would deop the person. Other services also deop that person.

This is new behaviour in 2.0.x.


2015-03-10 18:35

manager   ~0006705

From what I can see in that log file, there is nothing wrong and seems to be all intended behavior. You actually need SECUREOPS to be ON at all times if you do not wish to have any unauthorized persons have operator status in the channel.


2015-03-08 18:32

developer   ~0006704

New file uploaded, passwords in the log are throw-away. Any real passwords were removed.


2015-03-08 18:31


services.log.20150308 (39,544 bytes)


2015-03-08 14:13

administrator   ~0006702


I removed the file that was attached here as it contained a working password for your nick.

Can you upload it again with your password removed :>

Issue History

Date Modified Username Field Change
2015-03-04 04:03 azander New Issue
2015-03-04 04:03 azander File Added: services.log.20150304
2015-03-04 04:05 azander File Deleted: services.log.20150304
2015-03-04 04:06 azander File Added: services.log.20150304
2015-03-08 14:12 chaz File Deleted: services.log.20150304
2015-03-08 14:13 chaz Note Added: 0006702
2015-03-08 18:31 azander File Added: services.log.20150308
2015-03-08 18:32 azander Note Added: 0006704
2015-03-10 18:35 Robby Note Added: 0006705
2015-03-10 18:46 azander Note Added: 0006706
2015-03-11 03:01 NoMiaus Note Added: 0006707
2015-03-11 03:11 Adam Note Added: 0006708
2015-03-11 03:42 azander Note Added: 0006709
2015-03-11 16:26 Adam Note Added: 0006710
2015-03-12 02:20 azander File Added: configs.tar.bz2
2015-03-12 02:23 azander Note Added: 0006712
2015-03-12 19:00 Adam Note Added: 0006722
2015-03-23 14:00 Adam Note Added: 0006724
2015-03-23 14:00 Adam Status new => resolved
2015-03-23 14:00 Adam Resolution open => fixed
2015-03-23 14:00 Adam Assigned To => Adam