View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002050 | unreal | ircd | public | 2004-09-01 18:01 | 2006-04-16 18:35 |
| Reporter | Mekonikum | Assigned To | syzop | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | SuSE 9.0 | OS Version | 2.4.25 |
| Product Version | 3.2.1 | ||||
| Fixed in Version | 3.2.5 | ||||
| Summary | 0002050: ban-bug with restricted channel and vhost's | ||||
| Description | If 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 Information | postet a week ago in the anope forum, and they said it's a unreal bug. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Can you verify that the cloak keys are the same on all servers? (/stats S)? |
|
|
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 ? |
|
|
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 |
|
|
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. |
|
|
Okay, I will tell them. ;) Let's see what they say. :D |
|
|
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? |
|
|
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 :) |
|
|
>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? |
|
|
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 |
|
|
> 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. |
|
|
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...). |
|
|
um would it break code if a third one for *vhost* only was made? |
|
|
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. |
|
|
Ok, would anything be broken if +t merged with +x? |
|
|
Fixed in .489. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-09-01 18:01 | Mekonikum | New Issue | |
| 2004-09-01 18:09 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
Relationship added | related to 0002469 |
