View Issue Details

IDProjectCategoryView StatusLast Update
0003044unrealircdpublic2006-09-03 16:00
ReporterJasonTikAssigned Toaquanight 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformOS*OS Version*
Product Version3.2.5 
Target VersionFixed in Version3.2.6 
Summary0003044: SVSNICK Collisions
DescriptionWhen services sends SVSNICK User1 User2 1, if User2 exists, timestamps are not obeyed, but User1 is killed. This is annoying, and imo, either services should win, or timestamps should win. Also, case changes result in a collision when they shouldnt.
TagsNo tags attached.
3rd party modules

Activities

djGrrr

2006-08-31 08:43

reporter   ~0012268

If this is to do with nick guesting causing collisions, then your best bet is to set your services to use svshold instead of creating an enforcer user, that way no collisions happen

JasonTik

2006-08-31 13:00

reporter   ~0012269

That is not the case. This has only to do with renaming users. No enforcer is created.

tabrisnet

2006-08-31 23:22

reporter   ~0012271

Personally I just do an is_online($nick) check in services before I use svsnick.

syzop

2006-09-01 04:58

administrator   ~0012272

[quote]if User2 exists, timestamps are not obeyed, but User1 is killed.[/quote]

You mean, User2 is killed, right? Yeah, that's intended.

aquanight

2006-09-01 13:36

reporter   ~0012282

Last edited: 2006-09-01 13:39

Actually, User1 is.

if (find_client(parv[2], NULL)) /* Collision */
    return exit_client(cptr, acptr, sptr,
        "Nickname collision due to Services enforced "
        "nickname change, your nick was overruled");

syzop

2006-09-01 17:46

administrator   ~0012284

Last edited: 2006-09-01 17:46

Hm, I see. I wouldn't be surprised if the intention was to kill User2.

Maybe codemastr can shed some light on this.

(Unrelated, but.. in any case, we should not 'return' with an 'exit_client()' for another user, since that will incorrectly return FLUSH_BUFFER for a client that STILL EXISTS)

codemastr

2006-09-02 12:34

reporter   ~0012292

I *think* this was intended. The logic (as I remember) is as follows:

Services generally changes nicknames of users for 1 reason - the nickname he/she is using is invalid. It is invalid because either a.) it is registered to someone else, b.) it's an "unallowed" nickname (qlines), c.) something else along those lines that we never considered. A key point here to remember is the IRCd is never designed for RAW commands. Unreal isn't considering at all the fact that you just want to have fun with people's nicknames.

Anyway, when one of these invalid nicknames is detected, services may issue on SVSNICK to change the user's nickname to something legal (an alternative to just killing the user. Remember, the user didn't necessarily try to do something wrong, so a kill is harsh).

So I logon as JasonTik, services decides to change my name to Guest12345. However, someone else is already online with the nickname Guest12345. That user has done nothing wrong. He/she chose a 100% legal nickname to use. Or for that matter, may have been assigned that nickname by a previous SVSNICK. So, why should he be killed in this collision? *I* the person who logged on as JasonTik am the one who violated the rules. Hence, I'm the one who gets punished, by being killed. The "loser" in the collision is, in my opinion, the guy who is currently trying to take someone elses nickname (me). The alternative, of course, would be to have services continually do an while(nickExists(guestNick)) guestNick = newGuestNick();. That too solves such issues. But I don't see this as wrong on our part.

I think the logic is correct (though I agree with you the case changing may be an issue).

aquanight

2006-09-03 14:51

reporter   ~0012299

Case-change and returning FLUSH_BUFFER fixed in .2262.

I also noticed (and fixed) that QUIT wasn't being sent back toward services on a collision (which would no doubt cause massive desynchs).

JasonTik

2006-09-03 15:08

reporter   ~0012300

Services should have enough intelligence to not reuse a Guest nick when SVSNICKing a user. If services did SVSNICK a user to an existing user intentionally it was because it was doing some sort of auto-NICK-on-IDENTIFY thing. I identify to Jason, i get SVSNICKed to Jason. My clone/ghost/etc is gone. I have seen services that do this.

I see case changes have been fixed, but what has been decided on the Timestamp/User1/User2 thing?

tabrisnet

2006-09-03 15:11

reporter   ~0012301

I have been debating writing a GIDENTIFY which would ghost, and SVSNICK.
but it would specifically KILL or SVSKILL first

syzop

2006-09-03 16:00

administrator   ~0012302

Last edited: 2006-09-03 16:03

Fix for case-change thingy is in 3.2* and 3.3*.

As for 'who to kill', codemastr's reasoning sounds logical for the purpose of SVSKILL that he means.

If there should be another SVSNICK which kills the 'target client', I suppose one could suggest a SVS2NICK or something.

EDIT: NICK, not KILL... tnx aquanight ;p

Issue History

Date Modified Username Field Change
2006-08-30 17:48 JasonTik New Issue
2006-08-31 08:43 djGrrr Note Added: 0012268
2006-08-31 13:00 JasonTik Note Added: 0012269
2006-08-31 23:22 tabrisnet Note Added: 0012271
2006-09-01 04:58 syzop Note Added: 0012272
2006-09-01 13:36 aquanight Note Added: 0012282
2006-09-01 13:39 aquanight Note Edited: 0012282
2006-09-01 17:46 syzop Note Added: 0012284
2006-09-01 17:46 syzop Note Edited: 0012284
2006-09-02 12:34 codemastr Note Added: 0012292
2006-09-03 14:01 aquanight Status new => assigned
2006-09-03 14:01 aquanight Assigned To => aquanight
2006-09-03 14:51 aquanight Note Added: 0012299
2006-09-03 15:08 JasonTik Note Added: 0012300
2006-09-03 15:11 tabrisnet Note Added: 0012301
2006-09-03 16:00 syzop Status assigned => resolved
2006-09-03 16:00 syzop Fixed in Version => 3.2.6
2006-09-03 16:00 syzop Resolution open => fixed
2006-09-03 16:00 syzop Note Added: 0012302
2006-09-03 16:03 syzop Note Edited: 0012302