View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002613 | unreal | ircd | public | 2005-08-04 17:31 | 2015-07-09 18:51 |
| Reporter | Stealth | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| OS | all | OS Version | all | ||
| Product Version | 3.2.3 | ||||
| Fixed in Version | 3.4-beta1 | ||||
| Summary | 0002613: Usermode +t suggestion | ||||
| Description | If usermode +t means the user has a vhost, I think unsetting just the +t should return the host to the normal cloaked host... Example: If a user has rox-1234ABCD.somehost.com, and gets the vhost oper.mynet.com, he will have umodes +xt. If he unsets the +t leaving him with just +x, his host should return to rox-1234ABCD.somehost.com. I think this would be better than having to -x and +x, it is cleaner and more simplified with just having to -t. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Would be useful for HostServ OFF type stuff... :) |
|
|
Indeed, and also for not reveiling the real hostname in the process of doing -xt and +x again :) |
|
|
very nice idea:) |
|
|
I second this proposal. The current HS OFF method is a royal pain. |
|
|
I think this might actually be possible to implement now, given that services coders now can know the cloakhost. What I'm not sure on however is if this should be dependent on PROTOCTL CLK. Possibly what could be done is, if(SVS2MODE -t) { if (CLK) { /* do nothing */ } else { sendto_server { CHGHOST <cloakhost> } } that's rough pseudo code tho. |
|
|
Also, can we count on getting UMODE updates for umodes +x & +t now, or do we have to hack it ourselves for our umode tracking? If we don't receive it, can we safely assume that for any CHGHOST/SETHOST we receive, that we can set +xt ? |
|
|
That's terribly incorrect. There is no need to "hack". The reasons why on an UnrealIRCd that you would not be notified of your mode changing are: * Someone modified source and disabled it (unlikely) * The person, server, or thing that changed your usermode sent SVSMODE, which does not notify you of the change (most likely) * Your client is broken, or a script is blocking it from processing modes (possible, but not likely) Currently, CHGHOST doesnt notify you (it uses SVSMODE form). This is because its not SUPPOSED to tell the user. There are reasons why you'd want to CHGHOST and not inform the user. Lets say, for instance, you have some script kiddie on an inappropriate vhostname, and you want to change him before he joins all the family channels and scars children for life. If CHGHOST notified him, he'd see * MyBadSelf sets mode: +xt and promptly think to himself.. WTF!? and disconnect/connect. Sure, you can argue that you could ban it, but, is banning really the answer to everything? </ramble> Anyway I vote to keep CHGHOST usage hidden from the target (unless of course it's an oper, then they can see the SNOTICE...) |
|
|
Thank you for that education on CLIENT PROTOCOL. I am speaking in terms of SERVER PROTOCOL. Additionally, I am speaking of when a CHGHOST occurs, we don't receive a UMODE2 update. I even checked, just to be sure. with 3.2.5, with CLK enabled. |
|
|
If you're using CLK without VHP, you can pretty much assume all (CHG|SET)HOST is a +xt, since you'll never receive them for any reason (and you still have the cloakhost as long as you use NICKv2 :P ). But the umode syncing stuff is a completely different bug that I recall posting already ... Back on topic about MODE -t, I really do think it'd be nice to have. It's annoying to have to -x, then +x, and have that <1sec of exposed realhost/realip. Even more annoying with set::allow-userhost-change = force-rejoin. Then EVERYONE gets your realhost/realip without even having to whois you within the one second for it. |
|
|
And some networks (like mine) have set::restrict-usermodes x, so users cannot -x and +x to reset their host |
|
|
Well, we wouldn't necessarily require that users be able to -t themselves. We could only allow HS OFF to do it. It's not as if users can manipulate it directly now, any more than they can manipulate +r. |
|
|
Ok. Stupid Question Time. How difficult/trivial is this? Is this as obvious as it sounds? Insert some changes to the SVSMODE handler in the ircd? This is pseudocode, in a C style. Please don't hurt me. if(!MyClient(targetptr)) { if((umode -t) && !(umode -x)) { sptr->vhost = sptr->cloakhost; } else if(umode -x) { sptr->vhost = sptr->realhost; } } I think the big problem is that we might need to do the following additionally, before this is 'safe' if(isUline(sptr) && (sptr->flags & CLK)) { /* copy above pseudocode */ } since it is a functional change, and we can't assume that old services packages will know, but since CLK is new enough... |
|
|
bump. still an issue? if so, the suggestion of this bug report seems like a logical change. |
|
|
While working on something else I noticed this is still the case. I'll change it so -t does what -tx & +x does right now. As discussed in this report. ... but not today, today I'm done ;) |
|
|
https://github.com/unrealircd/unrealircd/commit/f3199ec5e519d74733b71341efc07a0b0fa54b98 commit f3199ec5e519d74733b71341efc07a0b0fa54b98 Author: Bram Matthys <[email protected]> Date: Thu Jul 9 18:43:21 2015 +0200 1) unset the swhois you got via a vhost upon MODE -t. 2) allow MODE yourself -t which will unset your vhost & give you a cloaked host (0002613, suggested by Stealth) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-08-04 17:31 | Stealth | New Issue | |
| 2005-08-23 17:18 | aquanight | Note Added: 0010381 | |
| 2005-12-22 18:03 | Robby22 | Note Added: 0010884 | |
| 2005-12-22 18:50 | vonitsanet | Note Added: 0010885 | |
| 2005-12-27 15:45 | tabrisnet | Note Added: 0010896 | |
| 2005-12-27 17:32 | syzop | Status | new => acknowledged |
| 2006-06-25 18:48 | tabrisnet | Note Added: 0012012 | |
| 2006-06-25 19:01 | tabrisnet | Note Added: 0012013 | |
| 2006-06-25 23:07 | Zell | Note Added: 0012014 | |
| 2006-06-25 23:17 | tabrisnet | Note Added: 0012018 | |
| 2006-06-25 23:18 | tabrisnet | Note Edited: 0012018 | |
| 2006-06-25 23:29 | aquanight | Note Added: 0012020 | |
| 2006-06-25 23:30 | aquanight | Note Edited: 0012020 | |
| 2006-07-01 19:34 | Stealth | Note Added: 0012034 | |
| 2006-07-01 20:19 | tabrisnet | Note Added: 0012035 | |
| 2006-07-01 20:59 | tabrisnet | Note Added: 0012036 | |
| 2015-05-27 18:27 | syzop | Note Added: 0018363 | |
| 2015-06-21 21:48 | syzop | Assigned To | => syzop |
| 2015-06-21 21:48 | syzop | Status | acknowledged => assigned |
| 2015-06-21 21:49 | syzop | Note Added: 0018411 | |
| 2015-06-21 21:50 | syzop | Note Edited: 0018411 | |
| 2015-07-09 18:51 | syzop | Note Added: 0018435 | |
| 2015-07-09 18:51 | syzop | Status | assigned => resolved |
| 2015-07-09 18:51 | syzop | Fixed in Version | => 3.4-beta1 |
| 2015-07-09 18:51 | syzop | Resolution | open => fixed |
