View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002186 | unreal | ircd | public | 2004-11-16 15:58 | 2004-12-09 12:32 |
| Reporter | Zell | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Platform | * | OS | * | OS Version | * |
| Product Version | 3.2.2 | ||||
| Summary | 0002186: Local Operators get error when setting ChMode +O | ||||
| Description | On a network with a few servers including a hub, a Local Operator does: (server: leaf3.test.net) /mode #test +O and receives this message raw: Hub.test.net 481 Zell :Permission Denied- You do not have the correct IRC operator privileges I know exactly why this is happening, the server says well i dont see you as an oper, so error on your command. However, the remote server shouldn't be concerned with what the remote user is doing, since if it is being sent to the network then it has already been assumed correct by the local server. | ||||
| Steps To Reproduce | 1) Create net with 1 hub and 2 or more leaf servers 2) set up olines, with a local oper line on one of the leafs 3) opper up and join a room 4) set the room +O 5) get an error from the hub (or possibly one of the other servers, depending on topology) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| duplicate of | 0001946 | resolved | cmode +O not accepted by remote servers when set by locops |
|
|
This is intentional. Servers in the past were rejecting the +O channel mode from locops on other linked servers, so it was decided that Global or higher would be required to set channel mode +O. EDIT: IIRC, channel mode +O was changed to do this in 3.2 or 3.2.1 |
|
|
In unreal they added the ability for Local operators to join +O rooms and to modify the +O chmode. I remember conversing in a bug about Locops not being able to join +O. The error here as I have now discovered, is not only the fact that the hub send you an error... I notice now that the hub on the network not only sends me a remote Numeric, but it also blocks the ChMode +O from going to the rest of the net. Short Story: Channel mode Desync! My server had +O, the rest did not. Hey!! Stay out of my room willya?!?!?! LoL. |
|
|
My bet is because it is of course because servers do not know of the local oper status. But if global oper or up is required to set +O, why doesn't the local server enforce that? |
|
|
Block local opers from setting +O. (I'm not sure for this:P) On channel.c if ((chptr->mode.mode & MODE_OPERONLY) && !IsAnOper(sptr)) return (ERR_OPERONLY); I think this shout be changed to: if ((chptr->mode.mode & MODE_OPERONLY) && !IsOper(sptr)) return (ERR_OPERONLY); Or inform all server for the local oper status. |
|
|
Used to be that way. I participated in the bugnotes getting locops to be able to join +O and to set +O. Though I guess we missed the fact that setting modes is checked remotely... LoL. maybe add a if (myclient) something somewhere to make the server only check modes if its a local client. as has been said about things before, if its being sent to the network, the local server has already authorized the action and therefore no further b*tching should be done by any servers... LoL |
|
|
[quote]maybe add a if (myclient) something somewhere to make the server only check modes if its a local client. as has been said about things before, if its being sent to the network, the local server has already authorized the action and therefore no further b*tching should be done by any servers... LoL[/quote] Well, the thing is servers do validate remote mode stuff, and that's a good thing because then you avoid odd problems caused by op desynchs. It also works to stop local opers from having can_override... heh :) . Anyway, I'm not really so sure if local operators should be setting +O ... joining is one thing - setting it is another. But what I want to know is, why doesn't the remote server bounce the mode (since most of the time it does bounce invalid changes...). |
|
|
Heh. It -Does- bounce the mode. Just not locally. You are permissioned to set it on your local server, no problem. The linked server then bounces it back because it doesnt see your ops. Thus, only your server can see the +O. IOW, if I set +O, remote denys it, then remote normal users can join the channel. Since the servers don't do remote Join checking, they are allowed in. The whole denying the mode remotely thing is kinda why I reported this... LoL.. |
|
|
Bounce meaning the remote server takes the responsibility of telling the local server it's wrong. Like how sometimes servers will bounce +o changes (sending a -o back down the path it come from - happens with uline errors for example). Shouldn't the remote server say "Hey. He can't set +O. Send back a -O." |
|
|
Should. Doesnt. The remote server just refuses to propagate the mode. Local mode stays. |
|
|
Digging through the bugs a bit (was looking for something else, but stumbled on it) I found a duplicate :P 0001946 :P |
|
|
Indeed, see 0001946 (I'll bump that one). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-16 15:58 | Zell | New Issue | |
| 2004-11-16 17:27 | Stealth | Note Added: 0008350 | |
| 2004-11-16 17:29 | Stealth | Note Edited: 0008350 | |
| 2004-11-16 19:57 | Zell | Note Added: 0008354 | |
| 2004-11-16 20:20 | aquanight | Note Added: 0008356 | |
| 2004-11-17 11:35 | syzop | Status | new => confirmed |
| 2004-11-18 08:29 | vonitsanet | Note Added: 0008365 | |
| 2004-11-18 08:34 | vonitsanet | Note Edited: 0008365 | |
| 2004-11-19 16:41 | Zell | Note Added: 0008377 | |
| 2004-11-19 17:02 | aquanight | Note Added: 0008380 | |
| 2004-11-22 22:15 | Zell | Note Added: 0008387 | |
| 2004-11-23 03:15 | aquanight | Note Added: 0008388 | |
| 2004-11-26 22:46 | Zell | Note Added: 0008417 | |
| 2004-12-08 23:40 | aquanight | Note Added: 0008559 | |
| 2004-12-09 12:30 | syzop | Relationship added | duplicate of 0001946 |
| 2004-12-09 12:32 | syzop | Status | confirmed => closed |
| 2004-12-09 12:32 | syzop | Note Added: 0008564 |
