View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002950||unreal||ircd||public||2006-06-06 17:38||2006-06-06 17:58|
|Platform||Linux/x86||OS||Debian Linux||OS Version||testing|
|Target Version||Fixed in Version||3.2.5|
|Summary||0002950: SVSHOLD/qline-H nicks still produce qline rejection notices|
|Description||My understanding is that svsholds are supposed to suppress both the notice for add/expire/delete, as well as rejected/blocked nick-changes.|
|Steps To Reproduce||start using SVSHOLD in services, and have a user try to use that nick while it is qlined/enforced. Note notice "Q:lined nick <foo> from <bar> on <baz>"|
|Tags||No tags attached.|
|3rd party modules|
Supposed to go into 'steps to reproduce'
start using SVSHOLD in services, and have a user try to use that nick while it is qlined/enforced. Note notice "Q:lined nick <foo> from <bar> on <baz>"
The way I read the code.. that could only happen if a svshold is on a server but then on a remote server someone changes his/her nick into such a svshold'ed nick. This would obviously be quite weird, since on the remote server it should also be on-hold and no user should be able to use that nick.
Even thinking of lag, it's not possible to reach such a situation (unless I'm missing something), since services should unhold it before anyone could use it (or unhold it before SVSNICK if that is used), so still synchronically ok (unhold, nickchange/forcednickchange), however you do it.
||oh ok, I'll try that.|
After reading the code, I think I have an idea of how it occurs.
a) it's line 263 of modules/m_nick.c, "remote user changing nick"
b) it occurs when the user manages to change nick either before the TKL entry expires (locally), or possibly before the TKL - Q message is received locally (unlikely).
Thus it appears likely to be a race. I am not _sure_ of this however.
[quote]and have a user try to use that nick while it is qlined/enforced.[/quote]
Oh wait.. you mean an oper ?
Since I don't get any notices otherwise here.
||I admit it shouldn't happen, but at the least, I do have it happening right now. The simplest fix (tho not necessarily the right fix) is to just add !ishold to the end of line 263's if(...)|
||Only opers are receiving the notices, but no, the users who are triggering the Q:line notices are _not_ opers.|
ah ok, makes sense.. didn't think of expiry :P
EDIT: I love the asynchronous comment posts here :P
||I'll get the !ishold added|
Fixed in CVS .532
- Got rid of qline notice that could happen if using services holds (semi-race condition),
reported by tabrisnet (0002950).
- if (IsServer(cptr) && IsPerson(sptr)) /* remote user changing nick */
+ if (IsServer(cptr) && IsPerson(sptr) && !ishold) /* remote user changing nick */
|2006-06-06 17:38||tabrisnet||New Issue|
|2006-06-06 17:45||tabrisnet||Note Added: 0011889|
|2006-06-06 17:47||syzop||Note Added: 0011890|
|2006-06-06 17:49||syzop||Note Added: 0011891|
|2006-06-06 17:51||tabrisnet||Note Added: 0011892|
|2006-06-06 17:53||syzop||Note Added: 0011893|
|2006-06-06 17:53||tabrisnet||Note Added: 0011894|
|2006-06-06 17:54||tabrisnet||Note Added: 0011895|
|2006-06-06 17:54||syzop||Note Added: 0011896|
|2006-06-06 17:55||syzop||Note Edited: 0011896|
|2006-06-06 17:56||syzop||Note Added: 0011897|
|2006-06-06 17:58||syzop||Status||new => resolved|
|2006-06-06 17:58||syzop||Fixed in Version||=> 3.2.5|
|2006-06-06 17:58||syzop||Resolution||open => fixed|
|2006-06-06 17:58||syzop||Assigned To||=> syzop|
|2006-06-06 17:58||syzop||Note Added: 0011898|