View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002933||unreal||ircd||public||2006-05-29 18:05||2006-11-03 17:38|
|Fixed in Version||3.2.6|
|Summary||0002933: SVSMODE +x error|
|Description||When services issue mode +x to restore users's original Cloak, instead of resetting the vhost, nothing is done and the vhost simply remains the same before svs/2/mode -xt|
|Steps To Reproduce||Log as a services, or get access to /os raw, after assigning a Vhost to you throught HostServ or such a service which sends CHGHOST to the client. Then send the text command throught the services server: :NickServ SVS2MODE <nick> -xt ;; then send :Nickserv SVS2MODE <nick> +x|
SVSMODE does the same as well... Other way to reproduce:
/CHGHOST <nick> a.given.vhost
/os raw :services.network.org v <nick> -xt
/os raw :services.network.org v <nick> +x
You may /whois the user between each command to see how the vhost will behave during each phase.
|Additional Information||SVSMODE does the same problem. As stated, the only difference between SVS2MODE to SVSMODE is that SVS2MODE still sends the mode change to the client, while SVSMODE no longer does.|
the 'v' command stands for SVS2MODE token.
You can't send by services a 'MODE, UMODE or UMODE2' which -would- do the trick. Ah. To reproduce 'normal' behavior (assuming mIRC client)
//CHGHOST $me a.given.vhost
//mode $me -x
//mode $me +x
All this were tested assuming ircd has the 'host cloak' with the three cloak-keys set, and all the same throughout the network, and services u-lined (as they can actually change any umode throught SVSMODE).
|Tags||No tags attached.|
|3rd party modules|
||Check out http://bugs.unrealircd.org/view.php?id=2565|
m_svsmode_modeaddx.patch (3,578 bytes)
RandomNumber, well, it is truly a solution for the problem. But there's still a miss: SVSMODE/SVS2MODE +x behave not like ordinary MODE +x. They just send the mode change (as applicable) and the UMODE_HIDE to the user pointer, but does not analyse if it is a case to re-calculate the Cloak (if no +t is present).
This patch I provided is to unreal 3.2.4 and will fix the issue by setting the behavior of SVSMODE 'x' case (when MODE_ADD) to the same as normal MODE would do (actually, I copied the code from m_mode.c and adapted the pointers to match the names from do_svsmode m_svsmode.c's function.
I am not intended in changing the ircd in any manner, take this patch as a suggestion, I prefer using out-of-box Unreal ircd code (without changing a singe line from the code), but as in the #unreal-support channel they seemed no care for the issue, and I should put services working, I were forced to make this patch and see things working by myself. The patch is not also bug-free, I have not tested it when multiple servers are on also.
EDIT: Ah, the point is: with the fix on the suggested link, there will supposedly still have the error with the mode change. That is: If a user logs on, and the ircd does not do host cloaking by default (it will not calculate the cloak then, right?), and services send a SVSMODE +x, the user will remain with the main IP instead of a cloak. This patch intends in issuing the same procedures ordinary /MODE would do if the own user types //mode $me +x (in mIRC for example). The procedures include issuing 'make_virthost()' which will generate the cloaked host if applicable. The same tests were copy-pasted from m_mode.c to m_svsmode.c.
I didn't know it had such odd behavior on -x/+x (oddly enough, bug 0002565 doesn't really make that clear), and my first reaction would too be "let's just fix that"... But.. second thing that comes up with my mind is: wouldn't it break stuff?
I'm thinking, maybe a better solution would be to act on -x: namely to free the vhost and put the cloaked host in that field (but not activate it). That way a (next) +x would use the cloaked host. So with SVSMODE target -xt+x you could then set the user cloaked (I know, just "-t" is nicer, but.. bleh). While still remaining compatible with services doing SETHOST, mode +xt (after all, when setting +x it might not know yet +t is going to be set, unless you want to look-ahead, blabla).
Problem is, we just went into testing stage a few days ago, and that basically means... "don't touch CVS right now!" ;). So will take a look at that post-3.2.5 (which is in 3 weeks).
Bad timing... can happen! ;)
Ah, you say to build the cloak (in the hidden host var or something like it) on -x mode. Right. So, don't forget to also fill that variable with the cloaked host 'on connection', cause I think that the +x does the make_virthost() upon connection so, if you change the procedure from +x to -x, maybe it will be needed then to have somewhere else the make_virthost() for new connections.
Well, just a reminder for when you look here at a later time. :}
Perhaps the +x and +t should all be (mostly) rewriten?
Then we can have proper -x/+x and -t reactions :)
Fixed in CVS (32* and 33*):
- Using SVSMODE (or SVS2MODE) to set -x will now actually remove the vhost from memory,
instead of letting it magically reappear whenever +x is set. This means services can
now properly "unvhost" a user by sending a "SVSMODE User -x+x" (then any existing vhost
will be removed and user will have a cloaked host). Reported by avenger and others
One note... I did not implement the denied/forcerejoin/etc stuff...... (yet?). Anyway that asside, it seems to work.
I tested things and they appear to work as expected... If you think anything is super-wrong, let me know.
|2006-05-29 18:05||avenger||New Issue|
|2006-05-29 18:08||RandomNumber||Note Added: 0011793|
|2006-05-30 08:51||avenger||File Added: m_svsmode_modeaddx.patch|
|2006-05-30 09:00||avenger||Note Added: 0011803|
|2006-05-30 09:09||avenger||Note Edited: 0011803|
|2006-05-30 10:19||syzop||Note Added: 0011804|
|2006-05-30 20:42||avenger||Note Added: 0011805|
|2006-05-30 23:21||Stealth||Note Added: 0011806|
|2006-05-31 07:20||syzop||Status||new => confirmed|
|2006-05-31 07:23||syzop||Relationship added||child of 0002936|
|2006-07-04 21:53||tabrisnet||Note Added: 0012055|
|2006-07-04 21:54||tabrisnet||Note Edited: 0012055|
|2006-07-04 21:54||tabrisnet||Note Edited: 0012055|
|2006-11-03 17:38||syzop||Status||confirmed => resolved|
|2006-11-03 17:38||syzop||Fixed in Version||=> 3.2.6|
|2006-11-03 17:38||syzop||Resolution||open => fixed|
|2006-11-03 17:38||syzop||Assigned To||=> syzop|
|2006-11-03 17:38||syzop||Note Added: 0012568|