View Issue Details

IDProjectCategoryView StatusLast Update
0002950unrealircdpublic2006-06-06 17:58
Reportertabrisnet Assigned Tosyzop  
Status resolvedResolutionfixed 
PlatformLinux/x86OSDebian LinuxOS Versiontesting
Product Version3.2.4 
Fixed in Version3.2.5 
Summary0002950: SVSHOLD/qline-H nicks still produce qline rejection notices
DescriptionMy understanding is that svsholds are supposed to suppress both the notice for add/expire/delete, as well as rejected/blocked nick-changes.
Steps To Reproducestart 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>"
TagsNo tags attached.
3rd party modules



2006-06-06 17:45

reporter   ~0011889

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>"


2006-06-06 17:47

administrator   ~0011890

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.


2006-06-06 17:49

administrator   ~0011891

oh ok, I'll try that.


2006-06-06 17:51

reporter   ~0011892

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.


2006-06-06 17:53

administrator   ~0011893

[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.


2006-06-06 17:53

reporter   ~0011894

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(...)


2006-06-06 17:54

reporter   ~0011895

Only opers are receiving the notices, but no, the users who are triggering the Q:line notices are _not_ opers.


2006-06-06 17:54

administrator   ~0011896

Last edited: 2006-06-06 17:55

ah ok, makes sense.. didn't think of expiry :P

EDIT: I love the asynchronous comment posts here :P


2006-06-06 17:56

administrator   ~0011897

I'll get the !ishold added


2006-06-06 17:58

administrator   ~0011898

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 */

Issue History

Date Modified Username Field Change
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