SVSNICK and cached ban status handling
After services does a SVSNICK on a user, if the new nickname is banned in a channel, they are still allowed to talk and change their nick if they were not banned previously. For example: *** Mode change "+b testing!*@*" on #test by RuneB *** Mode change "-o RuneB" on #test by RuneB <RuneB> I can talk. Now I'll force a SVSNICK on me to testing. *** RuneB is now known as testing <testing> can I still talk? <testing> yep. This is because is_banned doesn't recheck the ban list if the banserial has not changed for the user (instead it returns immediately). SVSNICK forces a nick change, but doesn't change the banserial in any of the channels the user is in. This causes is_banned to think the ban status has not changed. I have written a patch to fix this. After SVSNICK is done, it now goes through the channels the user is in and changes their cached banserial. is_banned will then recheck the ban list the next time it is called. For example, with the patch: *** Mode change "+b testing!*@*" on #test by RuneB *** Mode change "-o RuneB" on #test by RuneB <RuneB> I can talk. Now I'll force a SVSNICK on me to testing. This time, with a patch to force my banserial to be changed. *** RuneB is now known as testing <testing> can I still talk? *** #test Cannot send to channel <testing> nope. *** #test Cannot send to channel -- Ned T. Crigler
I like this! Too many times have I set a ban on guest*!*@somedomain only to watch an endless nick->guest->nick cycle. There are times when we don't want to remove a user from the channel, but we DO want to stop their lame script. Currently the only options are to kick the user or remove and re-set the ban... Both are undesdirable. In our off-list discussion you mentioned a case where this may still happen... Is there a solution other than changing banserial for every NICK event? -- Kevin Buley -----Original Message----- From: "Ned T. Crigler" <crigler@gmail.com> Date: Wed, 22 Apr 2009 22:54:04 To: <dalnet-src@lists.dal.net> Subject: [DALnet-src] SVSNICK and cached ban status handling After services does a SVSNICK on a user, if the new nickname is banned in a channel, they are still allowed to talk and change their nick if they were not banned previously. For example: *** Mode change "+b testing!*@*" on #test by RuneB *** Mode change "-o RuneB" on #test by RuneB <RuneB> I can talk. Now I'll force a SVSNICK on me to testing. *** RuneB is now known as testing <testing> can I still talk? <testing> yep. This is because is_banned doesn't recheck the ban list if the banserial has not changed for the user (instead it returns immediately). SVSNICK forces a nick change, but doesn't change the banserial in any of the channels the user is in. This causes is_banned to think the ban status has not changed. I have written a patch to fix this. After SVSNICK is done, it now goes through the channels the user is in and changes their cached banserial. is_banned will then recheck the ban list the next time it is called. For example, with the patch: *** Mode change "+b testing!*@*" on #test by RuneB *** Mode change "-o RuneB" on #test by RuneB <RuneB> I can talk. Now I'll force a SVSNICK on me to testing. This time, with a patch to force my banserial to be changed. *** RuneB is now known as testing <testing> can I still talk? *** #test Cannot send to channel <testing> nope. *** #test Cannot send to channel -- Ned T. Crigler -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Thu, Apr 23, 2009 at 10:25:07PM +0000, kevin@buley.org wrote:
I like this! Too many times have I set a ban on guest*!*@somedomain only to watch an endless nick->guest->nick cycle. There are times when we don't want to remove a user from the channel, but we DO want to stop their lame script. Currently the only options are to kick the user or remove and re-set the ban... Both are undesdirable.
In our off-list discussion you mentioned a case where this may still happen... Is there a solution other than changing banserial for every NICK event?
That problem is because SVSNICK is relayed to the person's server, which then does the forced nick change locally, and then sends out a standard NICK protocol message to the other servers. The other servers cannot tell the difference between a normal nick change and a forced nick change. This will cause remote servers to have the old user's banserial cached, since a normal NICK change doesn't change banserial right now. I think a flush of the banserial in m_nick in addition to m_svsnick is the easiest way to fix this, unless maybe SVSNICK is changed to not use a regular NICK protocol message to other servers. That unfortunately, would probably involve backwards-compatibility protocol issues. With the m_nick change, unpatched servers would just have a out-of-date banserial cached. -- Ned T. Crigler
participants (2)
-
kevin＠buley.org -
Ned T. Crigler