View Issue Details

IDProjectCategoryView StatusLast Update
0004680unrealircdpublic2016-05-22 15:48
ReportersoretnaAssigned Tosyzop 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSDebianOS Version8
Product Version4.0.2 
Target VersionFixed in Version4.0.4 
Summary0004680: Klines and Glines are only honored if set as *@host not user@host
DescriptionWhen I apply klines/glines with a user@host nothing happens. The user is still in the network/channels and can reconnect just fine. If I apply the gline/zline as *@host it works as expected. I am running version 4.0.2 in production and 4.0.3.1 in dev, the issue happens in both. I have also tried using +|-, insane-bans, -x, and many other things.

This is particularly important to handle web based clients that change hostmask info kiwiirc and irccloud both do this.
Steps To ReproduceApply gline to user@host, note that user is not removed from network and is still able to reconnect.

Apply gline to entire domain then the user is removed from network and not able to reconnect.

Additional InformationIn #unreal-support the following users reported experiencing this issue as well:
DBoyz
Valdebrick
TagsNo tags attached.
3rd party modules

Activities

syzop

2016-05-13 17:17

administrator   ~0019260

I'll see if I can verify this and then work out a fix.

Is this with or without set::options::identd-check? Just asking in case it matters...

dboyz

2016-05-13 19:52

reporter   ~0019261

Whether set::options::identd-check is added to the config file does not affect the result - I am able to reproduce this issue almost all the time except once.

*** G:Line added for DBoyz@192.168.1.101 on Fri May 13 17:33:52 2016 GMT (from DBoyz!~DBoyz@192.168.1.101 to expire at Fri May 13 17:34:02 2016 GMT: Test)

*** G:Line added for *D*@192.168.1.101 on Fri May 13 17:27:53 2016 GMT (from DBoyz!~DBoyz@192.168.1.101 to expire at Fri May 13 17:28:03 2016 GMT: Test)

*** G:Line added for *B*@192.168.1.101 on Fri May 13 17:28:13 2016 GMT (from DBoyz!~DBoyz@192.168.1.101 to expire at Fri May 13 17:28:23 2016 GMT: Test)

*** G:Line added for *o*@192.168.1.101 on Fri May 13 17:29:31 2016 GMT (from DBoyz!~DBoyz@192.168.1.101 to expire at Fri May 13 17:29:41 2016 GMT: Test)
*** You are banned from 123Talk (Test)
*** Client exiting: DBoyz (~DBoyz@192.168.1.101) [192.168.1.101] (User has been banned from 123Talk (Test))

*** G:Line added for *y*@192.168.1.101 on Fri May 13 17:30:45 2016 GMT (from DBoyz!~DBoyz@192.168.1.101 to expire at Fri May 13 17:30:55 2016 GMT: Test)

*** G:Line added for *z*@192.168.1.101 on Fri May 13 17:30:48 2016 GMT (from DBoyz!~DBoyz@192.168.1.101 to expire at Fri May 13 17:30:58 2016 GMT: Test)

*** G:Line added for *oy*@192.168.1.101 on Fri May 13 17:31:15 2016 GMT (from DBoyz!~DBoyz@192.168.1.101 to expire at Fri May 13 17:31:25 2016 GMT: Test)

*** G:Line added for *o*y*@192.168.1.101 on Fri May 13 17:31:22 2016 GMT (from DBoyz!~DBoyz@192.168.1.101 to expire at Fri May 13 17:31:32 2016 GMT: Test)

tl;dr - GLINE only worked for mask *o*@192.168.1.101 but my "hostmask" has always been DBoyz!~DBoyz@192.168.1.101

Additional information: There are no mask that matches my IP in the except::mask block, only:

except tkl { mask *@192.168.1.100; type all; };

Tizen

2016-05-14 04:13

reporter  

match.c.patch (132 bytes)

Tizen

2016-05-14 04:13

reporter   ~0019262

I have been able to replicate this problem and was able to track the issue down to the match_user function in match.c -- It appears that the if block deciding whether or not MATCH_USE_IDENT was sent to the function call was incorrectly pulling using acptr->username, rather than acptr->user->username.

I was able to resolve this issue by making the changes shown in the attached file match.c.patch

Tizen

2016-05-14 04:20

reporter   ~0019263

I can also explain why dboyz *o*@192.168.1.101 mask worked:

Currently the function sets client_username (the ident of the account being checked) using acptr->username. This value defaults to "unknown" and stays that way unless otherwise set. However the actual ident value of an account appears to be stored in acptr->user->username.

The reason *o*@192.168.1.101 "worked" had nothing to do with dboyz's actual ident, but because the system was checking it against unknown@192.168.1.101

dboyz

2016-05-14 06:19

reporter   ~0019264

I am able to confirm Tizen's statement above:

*** G:Line added for unknown@192.168.1.101 on Sat May 14 04:08:50 2016 GMT (from DBoyz!DBoyz@192.168.1.101 to expire at Sat May 14 04:08:51 2016 GMT: test)
*** You are banned from 123Talk (test)
*** Client exiting: DBoyz (DBoyz@192.168.1.101) [192.168.1.101] (User has been banned from 123Talk (test))

syzop

2016-05-22 15:48

administrator   ~0019265

Thanks, fixed now :)

commit 67c998dc9f758b8412585a34bddea8fc8d255ab4
Author: Bram Matthys <syzop@vulnscan.org>
Date: Sun May 22 15:44:28 2016 +0200

    Adding a GLINE or KLINE on usermask@ did not have any effect. Reported by soretna (0004680).
    Tizen, DBoyz and Valdebrick helped tracing the issue.
    Removed MATCH_USE_IDENT since it had no useful purpose.. for all cases one has to check identd first and then non-identd anyway.

https://github.com/unrealircd/unrealircd/commit/67c998dc9f758b8412585a34bddea8fc8d255ab4

Issue History

Date Modified Username Field Change
2016-05-12 22:42 soretna New Issue
2016-05-13 17:17 syzop Note Added: 0019260
2016-05-13 17:17 syzop Assigned To => syzop
2016-05-13 17:17 syzop Status new => acknowledged
2016-05-13 19:52 dboyz Note Added: 0019261
2016-05-14 04:13 Tizen File Added: match.c.patch
2016-05-14 04:13 Tizen Note Added: 0019262
2016-05-14 04:20 Tizen Note Added: 0019263
2016-05-14 06:19 dboyz Note Added: 0019264
2016-05-22 15:48 syzop Note Added: 0019265
2016-05-22 15:48 syzop Status acknowledged => resolved
2016-05-22 15:48 syzop Fixed in Version => 4.0.4
2016-05-22 15:48 syzop Resolution open => fixed