[IRCServices Coding] Bug using svs4-db in svs5 (autodeop/nojoin-level)

Wolfgang Urban ircservices-coding at tou.de
Sun Mar 28 11:19:44 PST 2004


Hi,

yesterday, a user told our staff that he was not able to op users who were
not on the channel's access list.

[19:41:58] *** Mode change [+o testuser] on channel #quizzing by papillio
[19:41:58] *** Mode change [-o testuser] on channel #quizzing by ChanServ

=ChanServ=   Information for channel #quizzing:
=ChanServ=   Options: Topic Retention, Op-Notice

As you can see, Secureops is deactivated.

Trying to op via '/chanserv op #quizzing testuser' results in:
=ChanServ=   Unable to op testuser on channel #quizzing.

On our network, we've been using Services5 for about a month. Before, we
used Services4; the channel #quizzing was registered under version 4 and the
founder modified the level settings completely. He also set AUTODEOP to
level 4. This was the problem:

After some investigation I found out that the level settings were
_completely_ taken over to Services5, including the level settings of
AUTODEOP and NOJOIN. As you know, in Services5 AUTODEOP and NOJOIN should
always be fixed to -1 and -100, and they are invisible to the user. To check
this, I modified services to also show those two levels in '/chanserv levels
list':

=ChanServ=   Access level settings for channel #quizzing:
[...]
=ChanServ=   _AUTODEOP     40
=ChanServ=   _NOJOIN      -20
[...]

The values were simply converted (new level=old level*10 in this case) like
any other level and are also being used to check user rights.

So if you have registered channels with Services4 with a positive AUTODEOP
or NOJOIN level and then use Services5, users without an access list entry
or too low access level may not be able to join the channel or get opped.
Since NOJOIN and AUTODEOP-settings can't be changed in v5, the founder has
to use '/chanserv levels reset' to work around this problem.

I was able to reproduce this bug with a new installation of Services 4.5.45
with clean databases, then using Services 5.0.29.
Hopefully this will get fixed in the next services release, i.e. by setting
both levels to -1 and -100 after reading the database.

If there are any problems understanding me/the bug, please ask.. ;)
Wolle