View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001946 | unreal | ircd | public | 2004-07-10 21:19 | 2005-02-03 20:08 |
| Reporter | Unim4trix0 | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Unix | OS | FreeBSD | OS Version | 4.9-STABLE |
| Product Version | 3.2.2 | ||||
| Summary | 0001946: cmode +O not accepted by remote servers when set by locops | ||||
| Description | when a locop sets a channel +O, it is rejected by all other servers, but their server accepts it thus some servers see the channel +O, and some see it -O in adition, locops are unable to join +O channels this only happens on servers with links | ||||
| Steps To Reproduce | oper up as a locop set a channel +O | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| has duplicate | 0002186 | closed | Local Operators get error when setting ChMode +O |
|
|
Bug Monitored: EddieK101 |
|
|
Does this problem happen in 3.2.1? |
|
|
The same error of the mode not propogating properly occurs the locops not being able to join +O is solved edited on: 2004-07-11 01:13 |
|
|
confirmed, locops can set mode +O and local server thinks it's ok but remote servers reject it (even on 3.2.1) -- fez |
|
|
Mabie restrict /mode #chan +O to global opers only? |
|
|
Negative. Putting a restrict on that umode would just be putting the IRCd back the way it was before 3.2.1 (locops cant join +O) -- ive noticed that bug b4... on my Net, we have to give Local opers a Global flag (O), but take off their global kill privileges... all that so they can get in the join-on-oper channel. the new ability for locops to join those rooms is great, probably just needs a little tweak somewhere ;-) |
|
|
maybe it's not the right place here - but it has also something to do with localops in +O-channels... some services-packages (ircservices for example) are taking a check on +O (and +A) channels if a joining user is allowed to be there - which means is an oper (is an admin) and kick'em if not. (rather senseful in case a +O channel gets empty and users who are joining before +O is set again would be able to stay in there...) I think this is because there is no global distribution of the existence of localops (umode +O) some may say, services should accept, that the ircd is working properly and that the ircd is handling joins and permissions correctly - which is partly true. But I can not really see any reasons why the umode O isn't distributed at the first place... (i think this localization <-> globalization-thingy has already been discused on some points (bugtracker - maillist?) - i didn't checked it up for now maybe someone has a link for a survey on this? ;) ) |
|
|
+O = Local Operator Why do other servers need to know about local operators on other servers, considering that they ARE local? If services wanted to check for a local operator, they could do :ChanServ WHOIS opernick opernick and see if the 313 reply (is an IRCop) comes before the 318 (end of WHOIS). |
|
|
If Services decided to trust that the IRC server was right, think about what it would do if a local oper were the first person to join a channel that was mode locked +O. Services would have to kick the user because it couldn't know if the user was joining normally or if they were a local oper, because the IRCd wouldn't have known that mode +O was going to be set and therefore didn't check whether the user should be allowed in. I'm not sure exactly what the solution here is, but I think the way it stands now doesn't work. :) |
|
|
Well, naturally if we change it, services would HAVE to follow... But there is one issue: even if the channel is ALREADY created and +O, if a local op joins, services that validate this will still kickban the oper... (I think). Currently the only sensible way to validate local opers is to send a far whois request and monitor the replies. |
|
|
Well right, assuming Services validates, then a local oper can't join at all. And if Services doesn't validate then you run into the issue I described with a local oper (or a regular user) being the first to join. edited on: 2004-07-14 20:00 |
|
|
uhh.. services don't kickban locops for joining +O chans already, why would they start? I think the only change that needs to be made is Locops can't set mode +O on channel (cut can still join them) |
|
|
Don't mean to drag further off topic, but that would depend on what services package you use -- IRCServices 5.0.36 certainly does just that. It will kick any local oper that joins a channel that has +O mode locked (it HAS to be mode locked +O, not just set +O). |
|
|
[15:53:10] * Now talking in #Opers [15:53:10] * irc.dragons.net sets mode: +ntG [15:53:10] * ChanServ ([email protected]) has joined #Opers [15:53:10] * ChanServ sets mode: +b *!~aquanight@*.dragons.net [15:53:10] * You were kicked from #Opers by ChanServ (You are not permitted to be on this channel.) (Despite the hostname, I was -o when doing this :P ) |
|
|
crappy. I wouldn't make services do that... So perhaps dont allow locops to join +O? or perhaps request the services coders redesign services? or perhaps make a "hack" where instead of just :user JOIN #chan it does :user MODE user +o :user JOIN #chan :user MODE user -o but still that would be a nasty hack....... otherwise, make locop modes get broadcast globally, and have remote servers "acknowledge" but not grant any extra priveleges? some thoughts -- fez |
|
|
>crappy. I wouldn't make services do that... Well that's IRCServices for you! :P |
|
|
locops can set +O on linked server ... But only they have a chanop status..(unreal say "Permission Denied- You do not have the correct IRC operator privileges" but works) I have 3 linked servers.. Example : (1): [02:29:49] * iMMortal sets mode: +wghsOxp - Server notice mask (+kcfFveGqsC) - You are now an IRC Operator now iMMortal join channel #test|O| #test|O| iMMortal StEiNi MaOaM #test|O| End of /NAMES list. [02:46:12] * Now talking in #test|O| iMMortal do : /mode #test|O| +O (nothig happens only error like [02:48:09] * iMMortal: you're not channel operator ) [02:52:04] <iMMortal> MaOaM I need OP pls i want to set +O [02:52:06] <iMMortal> :P [02:52:19] * MaOaM sets mode: +o iMMortal [02:52:20] <@iMMortal> Op meeeeeeee [02:52:23] <@iMMortal> thx [02:52:25] <MaOaM> :) [02:52:31] * iMMortal sets mode: +O (channel ist now +O but a error, ircd say : "Permission Denied- You do not have the correct IRC operator privileges" ) "in adition, locops are unable to join +O channels this only happens on servers with links" ? ? (mabye wrong linked ) The #oper channel ist +O and any locop can join .... (2): iMMortal join now in #test ( mlock for #test are +ntOs) [03:12:10] * Now talking in #test [03:12:10] * ChanServ sets mode: +sntrO [03:12:10] * ChanServ changes topic to 'locop +O test (iMMortal)' [03:12:10] * ChanServ sets mode: +oq iMMortal iMMortal it´s work..... The only bug I see is ==> Permission Denied- You do not have the correct IRC operator privileges :P edited on: 2004-07-14 21:20 |
|
|
You use IRCServices? :P That's the only servicepackage I know of that kicks -o users from +O channels, -AaN users from +A channels, and -z users from +z channels. (Though *pokes w00t* winse will probably support this as well :P .) Meaning Anope/Epona/Auspice probably doesn't do this. (And don't say ChanServ would allow a channel owner to go through - see my example!) |
|
|
I use Anope-1.7.4 :P aquanight all +O can join, not only chanowner lock : [03:26:28] * Now talking in #test [03:26:28] * ChanServ sets mode: +sntrO [03:26:28] * ChanServ changes topic to 'locop +O test (iMMortal)' [03:26:28] * ChanServ sets mode: -ahoq blabla blabla blabla blabla ^_^ |
|
|
Well for one, the channel wasn't +O when the oper actually joined :P . ChanServ sets it +O after the fact. And as I said, Anope probably doesn't enforce +OAz like IRCServices does :P . |
|
|
but now :P =================================== Info on: #test|O| Modes: +O Users: 3 Creation time: 2004-07-15 02:30:37 =================================== [03:38:58] * Now talking in #test|O| ;) Don´t know if enforce +OAz or not but works :) |
|
|
Crazy, as I said before, the local server DOES accept the chanmode +O, its the REMOTE servers that deny it. The local server will show the channel being +O, and the remotes will show it -O. There is a channel mode desync. |
|
|
Negative. Anope does -NOT- enforce +OAz on the first user joining. In fact, if you change mode +O or +A (ircd denys +z unless all are umode +z) while non-opers are in the room, Anope doesnt do anything. * Zell sets mode +O [nothing from services] * Zell sets mode +A [still, nothing] * Zell sets mode -AO ->ChanServ- set #otest mlock +AO * ChanServ sets mode +AO <Nonop> so when is this thing gonna kick me? Anope has a habit of doing that LOL... and if im not mistaken, I can mlock it to +z and it will set that even if non-SSL users are in the room (though they wont be let back in if they leave) |
|
|
Isn't that what I said? :P (Hm... Should it be possible to set +OA at the same time? :P ) |
|
|
Ok, that's enough debating this. Yes it affects some services. End of story. This isn't a place for you people to argue, it is a place to report bugs and suggest features. |
|
|
As this hasn't been marked resolved, i'll chime in again with an idea. Perhaps simply remove mode checking from remote servers. Have the local server check to make sure the mode change is allowed, then propgate it, and all other servers simply accept it without any fuss, similar to how JOIN is propogated as SJOIN |
|
|
ARggggggggggh *mark as private*. Anyway, I suppose codemastr simply forgot about this issue. The fix, or at least temporarely, is easy (just making it a local-only check). |
|
|
Fixed in .254 [well, not the services discussion of course] |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-07-10 21:19 | Unim4trix0 | New Issue | |
| 2004-07-10 22:13 | EddieK101 | Note Added: 0006984 | |
| 2004-07-10 23:43 |
|
Note Added: 0006985 | |
| 2004-07-11 00:22 | Unim4trix0 | Note Added: 0006986 | |
| 2004-07-11 01:13 | Unim4trix0 | Note Edited: 0006986 | |
| 2004-07-11 02:42 | fez | Note Added: 0006987 | |
| 2004-07-12 13:59 | vonitsanet | Note Added: 0007015 | |
| 2004-07-12 15:40 |
|
Status | new => assigned |
| 2004-07-12 15:40 |
|
Assigned To | => codemastr |
| 2004-07-14 12:26 | Zell | Note Added: 0007043 | |
| 2004-07-14 14:47 | medice | Note Added: 0007048 | |
| 2004-07-14 19:44 | aquanight | Note Added: 0007051 | |
| 2004-07-14 19:53 | Bergee | Note Added: 0007053 | |
| 2004-07-14 19:57 | aquanight | Note Added: 0007054 | |
| 2004-07-14 19:59 | Bergee | Note Added: 0007055 | |
| 2004-07-14 20:00 | Bergee | Note Edited: 0007055 | |
| 2004-07-14 20:07 | fez | Note Added: 0007056 | |
| 2004-07-14 20:11 | Bergee | Note Added: 0007057 | |
| 2004-07-14 20:15 | aquanight | Note Added: 0007058 | |
| 2004-07-14 21:15 | fez | Note Added: 0007059 | |
| 2004-07-14 21:17 | aquanight | Note Added: 0007060 | |
| 2004-07-14 21:18 | crazy | Note Added: 0007061 | |
| 2004-07-14 21:20 | crazy | Note Edited: 0007061 | |
| 2004-07-14 21:24 | aquanight | Note Added: 0007063 | |
| 2004-07-14 21:31 | crazy | Note Added: 0007066 | |
| 2004-07-14 21:33 | aquanight | Note Added: 0007067 | |
| 2004-07-14 21:42 | crazy | Note Added: 0007068 | |
| 2004-07-14 23:15 | Unim4trix0 | Note Added: 0007072 | |
| 2004-07-15 00:12 | Zell | Note Added: 0007076 | |
| 2004-07-15 00:15 | aquanight | Note Added: 0007077 | |
| 2004-07-15 12:54 |
|
Note Added: 0007093 | |
| 2004-12-09 12:30 | syzop | Relationship added | has duplicate 0002186 |
| 2004-12-10 03:42 | Unim4trix0 | Note Added: 0008576 | |
| 2004-12-10 11:21 | syzop | Note Added: 0008578 | |
| 2004-12-10 11:21 | syzop | View Status | public => private |
| 2005-02-03 20:06 | syzop | Severity | major => minor |
| 2005-02-03 20:06 | syzop | Product Version | 3.2-RC2 => 3.2.2 |
| 2005-02-03 20:06 | syzop | View Status | private => public |
| 2005-02-03 20:08 | syzop | Status | assigned => resolved |
| 2005-02-03 20:08 | syzop | Resolution | open => fixed |
| 2005-02-03 20:08 | syzop | Note Added: 0009014 |
