View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001640||Anope Stable (2.0.x series)||General||public||2015-03-04 04:03||2015-03-23 14:00|
|Summary||0001640: Channel giving ops when it shouldn't|
|Description||Set 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 Reproduce||Steps:|
* 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 Information||This has been tested with secureops on, and it works as expected when secureops is on.|
|Tags||No tags attached.|
||fixed in 303e652a3563c50d8836996851341840b1ad4277|
||This is from the keepmodes setting setting REGISTERED and conflicting with chanserv.cpp's take_modes registered check.|
||Configs from test server uploaded as requested. Only change to them is to remove passwords, except throw-away link password that doesn't matter.|
configs.tar.bz2 (35,809 bytes)
||I cannot reproduce this on a stock install of Unreal 3.2 latest and 2.0 git. Upload all of your configuration files.|
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?
||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.|
||I tested it, I followed your steps and ChanServ/BotServ deops the user...|
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.
||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.|
||New file uploaded, passwords in the log are throw-away. Any real passwords were removed.|
services.log.20150308 (39,544 bytes)
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 :>
|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|