View Issue Details

IDProjectCategoryView StatusLast Update
0004890unrealircdpublic2017-03-11 10:54
Reporterunic0rnAssigned Tosyzop 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version4.0.11 
Target VersionFixed in Version4.0.12 
Summary0004890: user info isn't properly propagated across the network
Descriptionserver A: linux
server B: windows, with anope services linked locally
server C: freebsd

scenario 1)
A-B-C
user on A cannot see the vhost of user on C

scenario 2)
B-C-A
user on B cannot see the vhost of user on A

no vhosts in whois, privmsg, notice, anything. windows server is 4.0.10, all the rest is 4.0.11, anope services are up to date.
TagsNo tags attached.
3rd party modules

Activities

syzop

2017-03-08 09:06

administrator   ~0019674

Last edited: 2017-03-08 09:07

View 2 revisions

Last time we had such a report we couldn't reproduce it. So I'm going to ask you before we try again:

How do you assign the vhost to the user? What is the exact procedure for us to reproduce it? Perhaps it matters.

Thanks!

unic0rn

2017-03-08 14:30

reporter   ~0019676

vhosts are assigned using anope's hostserv. as for the procedure, it should be simple - in both of the scenarios above vhosts don't get propagated. for a perfect match, i would say 2 servers running .11 on linux and one running .10 on windows, with current anope running on the windows server and linked to it, has to work - but i doubt that's the only scenario, i just didn't have time nor resources to test it more.

try connecting to irc.arloria.net, checking the network topology with map and experimenting with whois or perhaps who (i didn't check who tbh, but if privmsg and whois didn't show vhosts, neither will who) in #welcome on different servers if you wanna see it in action. i'll help with debugging if i can.

unic0rn

2017-03-09 02:11

reporter   ~0019677

well, i've figured it out, you shouldn't have problems with tracking it down now.

it fails to propagate vhosts for o-lined users only. basically, when oper has vhost set in unrealircd.conf, everything works fine. when oper has vhost set using anope (and no vhost in unrealircd.conf - at least that's the scenario tested), it behaves exactly as described above.

for regular users there's no problem. sorry for the confusion, i forgot one of the bots i was whoising, is o-lined as well, so basically i was accidentally checking only o-lined nicks.

unic0rn

2017-03-09 02:45

reporter   ~0019678

ok, it's not that clear cut. let me describe the current situation.

1) the bug affects only o-lined users
2) current network setup:

A - freebsd, .11
B - windows, .10 + anope
C - linux, .11

3) when opered users on A had vhosts defined in anope only, those vhosts weren't visible to regular user on C
4) when opered users on A have vhosts defined in unrealircd.conf only, those vhosts are visible to regular user on C as they should
5) opered users on C have vhosts defined in unrealircd.conf only, yet those are not visible to regular user on A, but are visible to opered user on A

i hope that cleans it up a bit. i have access to only one server's config on the network, so my debugging capabilities are limited.

unic0rn

2017-03-09 03:04

reporter   ~0019679

some clarifications and corrections:
as for 3) and 4), can't check what oper on C sees, noone around.
also, scrap 5) from previous note.

basically, it's the same both ways - or so i hope. user on C with vhost in unrealircd.conf, has that vhost visible on C but not on A. i've messed up assuming it's visible to opers on A due to using /wii instead of /whois.

also, there's one opered bot on C that had vhost before and doesn't have it now, so while i've assumed its vhost is defined in unrealircd.conf, i'll go with a wild guess it's using chghost and somehow failed to use it properly. if its the other way around, i'll find out and let you know. for now, lets assume everything is as described in https://bugs.unrealircd.org/view.php?id=4890#c19677

syzop

2017-03-09 07:34

administrator   ~0019680

Thanks for all the tracing! Much appreciated.
I'll take a look at it later this week/weekend.

unic0rn

2017-03-09 10:03

reporter   ~0019681

no problem. also, sorry for the mess, my sleep patterns recently are screwed up and i obviously jump to conclusions here too much. just figured out one detail i've missed the previous time, which is kinda obvious:

"basically, it's the same both ways - or so i hope. user on C with vhost in unrealircd.conf, has that vhost visible on C but not on A."

so it's nothing like the same. that vhost is defined in unrealircd.conf - has to be, it's another oper and services have no record of his vhost whatsoever.

A - freebsd, .11
B - windows, .10 + anope
C - linux, .11

- oper vhosts set using anope for opers on A are invisible on C (bug)
- oper vhosts set using ircd.conf for opers on A are visible on C (yay)
- oper vhosts set using ircd.conf for opers on C are invisible on A (bug, and WTF?)

it makes no goddamn sense. i thought it was a matter of some conflict between propagating the anope-set vhost and opering up (i oper up after identifying with nickserv - didn't check it otherwise, i specify nickserv password as a server password), but now it seems it's something wrong with propagating oper vhosts in general.

additional note, i was doing some rerouting that ended up in the above situation and i did reconnect after rerouting (i'm oper on A), while the oper on C did not reconnect, so the different behaviour of his vhost propagation may have something to do with that. sadly, he didn't reconnect automatically after kill so i can't confirm that :)

anyway, if you'll have any trouble reproducing any part of it, let me know.

unic0rn

2017-03-09 10:15

reporter   ~0019682

heh. another small correction, i oper before identify - should be the other way around, but services are remote so oper kicks in faster, just checked.

syzop

2017-03-11 10:11

administrator   ~0019684

I can reproduce the following issue and it has to do with synching on link:
* server setup A-B-C
* link A<->B squits and reconnects
* the oper from server A looks ok on server A, on server B, but not on server C. On server C I don't see the vhost but the cloaked hostname (in my case)

So I have a lead.. something to work on.

syzop

2017-03-11 10:52

administrator   ~0019685

Fixed. Thanks for the report!

https://github.com/unrealircd/unrealircd/commit/0963cddd28b0e74d270d5d4c9914bb8846762723

commit 0963cddd28b0e74d270d5d4c9914bb8846762723
Author: Bram Matthys <syzop@vulnscan.org>
Date: Sat Mar 11 10:50:00 2017 +0100

    Vhosts were not synched correctly during linking. Reported by unic0rn (0004890).
    This was not really noticeable on 2 server networks, but in A-B-C linking setups
    a vhost of user A would not show on server C.

syzop

2017-03-11 10:54

administrator   ~0019686

Some more details of behavior prior to the above fix:
Note the also the 'xyz is using modes ....' line.
* On server B you see it is missing 't' in the modes line but the vhost is still effective nonetheless.
* On server C you also see the missing 't' but the vhost is not effective.

Issue History

Date Modified Username Field Change
2017-03-08 01:24 unic0rn New Issue
2017-03-08 09:06 syzop Note Added: 0019674
2017-03-08 09:07 syzop Note Edited: 0019674 View Revisions
2017-03-08 14:30 unic0rn Note Added: 0019676
2017-03-09 02:11 unic0rn Note Added: 0019677
2017-03-09 02:45 unic0rn Note Added: 0019678
2017-03-09 03:04 unic0rn Note Added: 0019679
2017-03-09 07:34 syzop Note Added: 0019680
2017-03-09 10:03 unic0rn Note Added: 0019681
2017-03-09 10:15 unic0rn Note Added: 0019682
2017-03-11 10:11 syzop Assigned To => syzop
2017-03-11 10:11 syzop Status new => confirmed
2017-03-11 10:11 syzop Note Added: 0019684
2017-03-11 10:52 syzop Status confirmed => resolved
2017-03-11 10:52 syzop Resolution open => fixed
2017-03-11 10:52 syzop Fixed in Version => 4.0.12
2017-03-11 10:52 syzop Note Added: 0019685
2017-03-11 10:54 syzop Note Added: 0019686