View Issue Details

IDProjectCategoryView StatusLast Update
0002050unrealircdpublic2006-04-16 18:35
ReporterMekonikum Assigned Tosyzop  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSSuSE 9.0OS Version2.4.25
Product Version3.2.1 
Fixed in Version3.2.5 
Summary0002050: ban-bug with restricted channel and vhost's
DescriptionIf a User joins a restricted channel (without permission) with his vhost set, and the chanserv ban's his cloaked host, the user can join.

vhost: launebaer.der.schreck
vhost: gamer-E9DEC783.ipt.aol.com

[13:30:32] * launebaer ([email protected]) has joined #IK-Team
[13:30:32] * ChanServ sets mode: +b *!*@gamer-E9DEC783.ipt.aol.com
[13:30:32] * launebaer was kicked by ChanServ (Dir ist es nicht erlaubt, diesen Channel zu betreten.)
[13:30:32] * launebaer ([email protected]) has joined #IK-Team
[13:30:32] * launebaer was kicked by ChanServ (Dir ist es nicht erlaubt, diesen Channel zu betreten.)
[13:30:32] * launebaer ([email protected]) has joined #IK-Team
[13:30:32] * launebaer was kicked by ChanServ (Dir ist es nicht erlaubt, diesen Channel zu betreten.)
[13:30:33] * launebaer ([email protected]) has joined #IK-Team
[13:30:33] * launebaer was kicked by ChanServ (Dir ist es nicht erlaubt, diesen Channel zu betreten.)
[13:30:33] * launebaer ([email protected]) has joined #IK-Team
[13:30:33] * launebaer was kicked by ChanServ (Dir ist es nicht erlaubt, diesen Channel zu betreten.)

Used Version:
Unreal 3.2.1
Anope 1.7.4 with latest unreal_addon mod by DukePyrolator
NEW cloak module
Additional Informationpostet a week ago in the anope forum, and they said it's a unreal bug.
TagsNo tags attached.
3rd party modules

Relationships

related to 0002469 closedsyzop SVSMODE -b and usermode 'x' 

Activities

codemastr

2004-09-01 18:09

reporter   ~0007467

Can you verify that the cloak keys are the same on all servers? (/stats S)?

Mekonikum

2004-09-01 18:21

reporter   ~0007468

I just checked the /stats S md5 of the cloak keys on every server linked, all the same.
Perhaps the same issue as in 0002045 ?

Mekonikum

2004-09-01 18:28

reporter   ~0007469

gamer-E9DEC783.ipt.aol.com is the cloaked host, not a vhost, sorry, write error.

vhost: launebaer.der.schreck
host: gamer-E9DEC783.ipt.aol.com

codemastr

2004-09-01 18:44

reporter   ~0007470

Actually, wait, now that I read this, this isn't a bug! +x sets a vhost. By using your HostServ, you have overridden that vhost and used another one instead.

There is really nothing we can do about this, it is working exactly as it is designed. This is the reason why /sethost is limited to opers. The fact that anope tries to set it on the +x host which is NOT the user's realhost is an anope bug. Once anope changes the user's host, that +x'ed host is gone and is completely meaningless for that user. They should be placing the ban on either the realhost (-x) or on the vhost, not on the +x'ed host.

Mekonikum

2004-09-01 20:54

reporter   ~0007471

Okay, I will tell them. ;)
Let's see what they say. :D

aquanight

2004-09-02 00:09

reporter   ~0007472

Hm... shouldn't a cloaked host ban be applied to the -x host all the same? IOW, shouldn't the ban check against the real host also run the cloak routine on it, regardless of a vhost?

codemastr

2004-09-02 02:27

reporter   ~0007473

Why? That would be horribly inefficient. We now have to run an MD5 hash every single time the user tries to join a channel. The system works like this:

You connect, Unreal generates a cloaked host and stores it in the "vhost."
You set +x, Unreal now says "use the vhost parameter."
You set -x, Unreal now says "ignore the vhost parameter (but does not delete it)".
You use /sethost, /chghost, /vhost, etc. Unreal replaces the current vhost (+x) with the new vhost.

Once again, you notice that none of the host change commands in Unreal grant general access. All of them require some form of access control, either being an oper, or being granted a vhost {} block. Either way it implies some form of trust by the server staff. It was never truly designed for these HostServ things. Perhaps storing the +x host as well is not a bad idea. However, that means more memory usage. It could mean as much as an additional 72 bytes of memory in use per user (though it would probably average lower). But 72 bytes imho is kind of a lot for such a minor change. I mean, it won't allow people to continually evade. They can only evade once before you just ban the new host. Seeing as how this is the first case of this I've heard of, and this particular instance is a result of a bug, I don't quite see this as being a major issue that would require such memory usage.

In any case though, I'll leave this bug report open until you hear back from the Anope guys. If they give you a hastle, let me know and I'll go yell at them for you :)

aquanight

2004-09-02 05:37

reporter   ~0007474

>You set -x, Unreal now says "ignore the vhost parameter (but does not delete it)".

Does "but does not delete it" even mean that if you had a custom vhost, it remains?

In other words, if I get /sethost'd and then -x, would I still be unaffected by cloak host bans, and still be affected by bans against my old vhost?

al5001

2004-09-03 04:26

reporter   ~0007479

Last edited: 2004-09-03 04:50

Would +t work for HostServ (or whatever ulined server) when setting vhosts?

edit:

For example, I get a ulined server to set my hostname to something else. If that ulined server also set my usermode to +t, would bans work normally again?

edited on: 2004-09-03 04:50

codemastr

2004-09-03 23:55

reporter   ~0007487

> Does "but does not delete it" even mean that if you had a custom vhost, it remains?
No. Read what I said, the next line answers your question, "You use /sethost, /chghost, /vhost, etc. Unreal replaces the current vhost (+x) with the new vhost." When you use /sethost or some other command, it overwrites the cloaked host. Unreal only stores 2 hosts for a user. The realhost, and the fake host. The fake host is either a cloaked host, or it is a vhost.

> Would +t work for HostServ (or whatever ulined server) when setting vhosts?

Regardless of whether +t is set, it will overwrite the cloaked host. You could make HostServ set +t if you like, but it still will overwrite the cloaked host.

aquanight

2004-09-04 02:11

reporter   ~0007490

codemastr, I think you misunderstood what I was asking :) .

When I connect, I get my realhost and cloaked host (and +x).
When I do /sethost, I get my vhost, which as you said overwrites the cloaked host.
When I do -x to make my real ip visible, will Unreal recalculate the cloaked ip and replace the vhost, or will the vhost remain until I +x again (at which IIRC it does recalculate the cloaked IP)? In the latter case, this means that even after I -x, I would still be affected by bans against my vhost, and not affected by bans against the cloaked host. In the former case, I would be back to normal ban matching (I guess...).

White_Magic

2004-09-19 14:47

reporter   ~0007718

um would it break code if a third one for *vhost* only was made?

codemastr

2004-09-19 16:11

reporter   ~0007721

White_Magic, you need to start reading the posts. A lot of questions you asked are already answered:

"Perhaps storing the +x host as well is not a bad idea. However, that means more memory usage. It could mean as much as an additional 72 bytes of memory in use per user (though it would probably average lower). But 72 bytes imho is kind of a lot for such a minor change."

I don't want to waste memory for such a minor feature.

al5001

2004-09-20 01:56

reporter   ~0007729

Ok, would anything be broken if +t merged with +x?

syzop

2006-04-16 18:35

administrator   ~0011563

Fixed in .489.

Issue History

Date Modified Username Field Change
2004-09-01 18:01 Mekonikum New Issue
2004-09-01 18:09 codemastr Note Added: 0007467
2004-09-01 18:21 Mekonikum Note Added: 0007468
2004-09-01 18:28 Mekonikum Note Added: 0007469
2004-09-01 18:44 codemastr Note Added: 0007470
2004-09-01 20:54 Mekonikum Note Added: 0007471
2004-09-02 00:09 aquanight Note Added: 0007472
2004-09-02 02:27 codemastr Note Added: 0007473
2004-09-02 05:37 aquanight Note Added: 0007474
2004-09-03 04:26 al5001 Note Added: 0007479
2004-09-03 04:27 al5001 Note Edited: 0007479
2004-09-03 04:48 al5001 Note Edited: 0007479
2004-09-03 04:50 al5001 Note Edited: 0007479
2004-09-03 23:55 codemastr Note Added: 0007487
2004-09-04 02:11 aquanight Note Added: 0007490
2004-09-19 14:47 White_Magic Note Added: 0007718
2004-09-19 16:11 codemastr Note Added: 0007721
2004-09-20 01:56 al5001 Note Added: 0007729
2006-04-16 18:35 syzop Status new => resolved
2006-04-16 18:35 syzop Fixed in Version => 3.2.5
2006-04-16 18:35 syzop Resolution open => fixed
2006-04-16 18:35 syzop Assigned To => syzop
2006-04-16 18:35 syzop Note Added: 0011563
2007-04-27 05:29 stskeeps Relationship added related to 0002469