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 |
| Reporter | tabrisnet | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux/x86 | OS | Debian Linux | OS Version | testing |
| Product Version | 3.2.4 | ||||
| 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 */ |
| 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 |
