View Issue Details

IDProjectCategoryView StatusLast Update
0002613unrealircdpublic2015-07-09 18:51
ReporterStealth Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
OSallOS Versionall 
Product Version3.2.3 
Fixed in Version3.4-beta1 
Summary0002613: Usermode +t suggestion
DescriptionIf 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.
TagsNo tags attached.
3rd party modules

Activities

aquanight

2005-08-23 17:18

reporter   ~0010381

Would be useful for HostServ OFF type stuff... :)

Robby22

2005-12-22 18:03

reporter   ~0010884

Indeed, and also for not reveiling the real hostname in the process of doing -xt and +x again :)

vonitsanet

2005-12-22 18:50

reporter   ~0010885

very nice idea:)

tabrisnet

2005-12-27 15:45

reporter   ~0010896

I second this proposal. The current HS OFF method is a royal pain.

tabrisnet

2006-06-25 18:48

reporter   ~0012012

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.

tabrisnet

2006-06-25 19:01

reporter   ~0012013

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 ?

Zell

2006-06-25 23:07

reporter   ~0012014

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...)

tabrisnet

2006-06-25 23:17

reporter   ~0012018

Last edited: 2006-06-25 23:18

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.

aquanight

2006-06-25 23:29

reporter   ~0012020

Last edited: 2006-06-25 23:30

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.

Stealth

2006-07-01 19:34

reporter   ~0012034

And some networks (like mine) have set::restrict-usermodes x, so users cannot -x and +x to reset their host

tabrisnet

2006-07-01 20:19

reporter   ~0012035

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.

tabrisnet

2006-07-01 20:59

reporter   ~0012036

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...

syzop

2015-05-27 18:27

administrator   ~0018363

bump. still an issue? if so, the suggestion of this bug report seems like a logical change.

syzop

2015-06-21 21:49

administrator   ~0018411

Last edited: 2015-06-21 21:50

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 ;)

syzop

2015-07-09 18:51

administrator   ~0018435

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)

Issue History

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