View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004350 | unreal | ircd | public | 2015-05-14 03:04 | 2015-07-12 17:26 |
| Reporter | Demonicpagan | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.10.4 | ||||
| Summary | 0004350: SETIDENT/ CHGIDENT not setting usermode +t | ||||
| Description | Along with what is in the summary, when you change the ident@ (chgident/setident), it does not check to see if it matches the current; it causes an update (& cycle if force-rejoin). Normally, vhost (chghost / sethost) will check & complain. usermode -t does NOT reset the ident. | ||||
| 3rd party modules | |||||
|
|
Right, okay, but why do you expect +t to be set when you SETIDENT or CHGIDENT? From /HELPOP ?UMODES: t = Says that you are using a /VHOST And when you /SETIDENT xyz it says: -maintest.test.net- Your nick!user@host-mask is now (xxx!yyyy@localhost) - To disable ident set change it manually by /setident'ing again Seems pretty clear. Of course if you spotted some documentation that suggests otherwise, do let us know (where) :) ** As for cycling even if you "change" to the exact same string as the current one, yeah that's just silly and should be fixed then. |
|
|
One of my admins made the following observations and ask that they be considered: The issue is: with clients that monitor their current hosts for security purposes (various scripts, XDCC clients, bots) and convenience (manually removing that stupid / useless "~" for those clients who can't run an IDENTd server), the only way they know a host-change occurred is via usermodes +x & +t. If the ident is changed (via /SETIDENT or /CHGIDENT) but not the host, there's nothing to tell the client their full userhost ([email protected] -> [email protected]) has changed. Besides the coding & security perspective [and the current documentation notwithstanding], it seems like "half the job" to show / acknowledge the host change but not the ident change. If *both* can not return information to the client about either change, then we need to be consistent: (1) don't allow ident change at all, (2) update usermode +t to alert to both, (3) create a new usermode to reflect a "vident" (for lack of a better explanation) to partner with +t & +x. Based on the comment made ("-maintest.test.net- Your nick!user@host-mask is now (xxx!yyyy@localhost) - To disable ident set change it manually by /setident'ing again" && "Seems pretty clear."), then why have usermode +t as all? By that same logic, you don't need usermode +t at all; usermode +x should suffice (and users should just code to sniff raw server notices for host changes as well as ident changes). One perspective: a dumb-ass IRCop decides to play a joke on a channel and change the ident of a known channel master so their hostmask does not appear as normal. Even with "force-rejoin" active, the user herself / himself never knows they channel-cycled (the other users see "Rejoining because of user@host change" as usual). Because nothing ***standard*** alerted them to the change (because not all users are mode +s / see all server notices in their status window / only watching channel window), they never realize to correct (report) the issue. Again, it's a matter of consistency / same method across the board. To the average user, "host" means [email protected] (not necessarily "nick!"). The terms "userhost," "hostname," "mask," & "host" are interchanged. Even in the UNREAL documentation, such ambiguities exist: 4.5 - ALLOW BLOCK ( "hostname <user@host-connection-mask>;" ) 4.7 - OPER BLOCK ( "userhost <hostmask>;" ) , ("The oper::from::userhost is a user@host mask that the user must match"), ("The oper::maxlogins allows you to restrict the number of concurrent oper logins from this ***host***, for example if you set it to 1 then only 1 person can be oper'ed via this block at any time. [optional]" yet "userhost [email protected];") 4.12 - TLD Block ("mask <hostmask>;" yet "The tld block allows you to specify a motd, rules, and channel for a user based on their ***host***") I found another 4 examples, then gave up reading. The point I'm trying to make is: because the ident & host/domain go together, they should BOTH have such consideration (usermode +t and usermode ... +n perhaps?). that, or, to make everything validate the documentation: disable SETIDENT / CHGIDENT altogether. |
|
|
Well, there's a big difference between changing your host and changing your username. I say username here to imply non-ident because identd is rarely ever used anymore. The username is something the user can freely pick, it's just sent in the USER command. That's not true for the host. SETIDENT was introduced for convenience so the user doesn't have to reconnect to change his/her ident (which would have resulted in the same new ident anyway) So that's why they are not treated the same, as they are not. |
|
|
To summarize: think of the username more as something like the nickname, the user can pick those freely when he/she connects. NICK allows you to change the nickname afterwards, SETIDENT does the same for the username. Changing IP's or hostnames is something entirely different, the user cannot just pick anything (well.. you know what I mean..) |
|
|
1. /SETIDENT works only on ones self, thus telling ones self about an action one just performed on ones self is redundantly redundant and shouldn't be listed in this bug as it indeed redundantly notifies ones self of that which one already knows because only they could have initiated /setident in the first place. 2. I'm really interested in hearing more about these "security purposes" that require bots/scripts to monitor their own hostmask in a manner that has thus far not been required for the last 20 years or so but today are suddenly required. 3. setident/chgident can be disabled for non-ulined clients in ./Config -advanced for networks that deem them disruptive. 4. "when you change the ident@ (chgident/setident), it does not check to see if it matches the current;" That is intentional because it's less expensive resource wise to just set the ident than to check and then set. The ircd also assumes that the IRCop knows what the ident currently is as well as what the ident is going to be set to. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-05-14 03:04 | Demonicpagan | New Issue | |
| 2015-05-18 12:01 | syzop | Note Added: 0018306 | |
| 2015-05-18 21:32 | Demonicpagan | Note Added: 0018317 | |
| 2015-05-24 11:03 | syzop | Note Added: 0018337 | |
| 2015-05-24 11:07 | syzop | Note Added: 0018338 | |
| 2015-05-26 00:39 | katsklaw | Note Added: 0018346 | |
| 2015-05-26 00:41 | katsklaw | Note Edited: 0018346 | |
| 2015-07-12 17:26 | syzop | Status | new => closed |
| 2015-07-12 17:26 | syzop | Assigned To | => syzop |
| 2015-07-12 17:26 | syzop | Resolution | open => no change required |
