View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003702 | unreal | ircd | public | 2008-06-16 00:04 | 2015-08-08 17:52 |
| Reporter | Bricker | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| OS | fuckoff | OS Version | srsly | ||
| Product Version | 3.2.9-RC1 | ||||
| Summary | 0003702: kick split-riders from +O / +A channels | ||||
| Description | basically, a user would be kicked out and/or not let back into a channel that is +O on a relink (after a netsplit). If they were in there for some other reason, like sajoined, they can be let back in, but maybe the person didnt remember them being in there etc. etc etc... | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
The point of channel mode +O is so that users without USER mode +o cannot join by themselves. There shouldn't be any way to bypass that without an opers assistance anyway. So to be honest I cant see how this could be considered a bug but that's just my opinion. If there is a way then its because you wasn't very clear with your explanation. The problem I see with doing anything about it is you open up the possibility for abuse by users to bypass channel mode +O when they shouldn't be allowed to. |
|
|
Jobe: "If they were in there for some other reason, like sajoined, they can be let back in, but maybe the person didnt remember them being in there etc. etc etc..." how unclear was that? If the user was SAJOINED into the channel but for whatever reason, someone(s) forgot said user was in the channel, they should be kicked out. ie, on reconnect all servers should enforce the modes to kick the user out etc |
|
|
Getting past it via netsplit is pretty trivial. Server is started, user connects, joins channel, server linked to network where channel is +O - user has bypassed +O. This is what no create on split is designed to solve (generically, and without bypass). |
|
|
Hm, not entirely sure if I'd want this. We did it for +z (kick insecure users out on resynch), which was a special case... +z is holy ;) I understand your (Bricker) point, though. We can see, however, that the TS is newer on the bypassing side, so we could take action on that.. Still... I get a feeling we are getting at uncomfortable terrain then :P I'm throwing it away from 3.2* for now. |
|
|
Bump |
|
|
we could do this if we are not doing a 'merge' but have different TS's. Otherwise, don't. Perhaps something for 3.2.10 |
|
|
+1 for throw it away. It may be inconvenient for a few people but that's not enough for me to be comfortable with needing a bypass. If a user was SAJOINed, then SAJOIN them again, problem solved. Not like this very specific event should happen on a regular basis. |
|
|
i am updating the title of this to be more descriptive of what we intend to do. |
|
|
I am on board with kicking users after connecting split/new servers from +A and +O channels, since I assume current oper flags (if they are logged in) could determine whether or not to kick. Furthermore, I think it would be nice if the kick could happen before other sync stuff, like setting the topic and showing users on the channel for privacy reasons. But it sounds to me like +i is a bit trickery. I'm personally against that change unless the logic of the mechanism can be assured. That's my 2ยข. |
|
|
There are number of things mentioned here: 1) +O / +A channels (with non-ircops/non-admins on it) 2) +i channels (with any user on it) And: A) Only kick users if their side has a newer creation time (split riding) B) Also kick users on equal TS Just to be clear: what I'm ok with is 1+A. 1+A is an easy case, as you can clearly see that the channel got recreated on the other side (1) AND that the user normally shouldn't be there (A, namely chmode +O/+A but umode not +o/+a). Applying it to B (equal TS as well), I see no reason for that. There shouldn't be any unwanted users with equal TS because the channel was still in a trusted state (bad term, but you get the idea..). With regards to applying it to other channel modes (case 2) like +i: I'd like to stay away from that, I doubt that's a good idea, can be highly annoying. Actually I don't think anyone here supports the +i case? Or? |
|
|
Thanks for clarifying that, the updated title was misleading. That's why I posted. |
|
|
Indeed. Changed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-06-16 00:04 | Bricker | New Issue | |
| 2008-06-16 00:04 | Bricker | Status | new => assigned |
| 2008-06-16 00:04 | Bricker | Assigned To | => nate |
| 2008-06-16 00:04 | Bricker | QA | => Not touched yet by developer |
| 2008-06-16 00:04 | Bricker | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2008-06-16 00:04 | Bricker | U4: Upstream notification of bug | => Not decided |
| 2008-06-16 00:04 | Bricker | U4: Contributor working on this | => None |
| 2008-06-19 15:38 | Jobe | Note Added: 0015308 | |
| 2008-06-19 15:39 | Jobe | Note Edited: 0015308 | |
| 2008-06-19 15:41 | Jobe | Note Edited: 0015308 | |
| 2008-06-19 16:07 | Bricker | Note Added: 0015309 | |
| 2008-06-23 14:26 | w00t | Note Added: 0015312 | |
| 2008-08-10 18:40 | syzop | Note Added: 0015360 | |
| 2008-08-10 18:43 | syzop | Note Edited: 0015360 | |
| 2008-08-10 18:43 | syzop | Product Version | 3.2.7 => 3.3-alpha0 |
| 2008-08-10 18:43 | syzop | Note Edited: 0015360 | |
| 2010-04-03 19:54 | Bricker | Note Added: 0016061 | |
| 2010-07-14 17:20 | syzop | Note Added: 0016170 | |
| 2010-07-14 17:20 | syzop | Assigned To | nate => |
| 2010-07-14 17:20 | syzop | Status | assigned => acknowledged |
| 2010-07-14 17:20 | syzop | Product Version | 3.3-alpha0 => 3.2.9-RC1 |
| 2010-07-14 17:21 | syzop | Relationship added | child of 0003776 |
| 2010-07-14 17:26 | syzop | Relationship deleted | child of 0003776 |
| 2010-07-14 17:26 | syzop | Relationship added | child of 0003915 |
| 2012-10-06 12:24 | syzop | Relationship deleted | child of 0003915 |
| 2013-02-24 03:11 | katsklaw | Note Added: 0017439 | |
| 2013-05-06 07:14 |
|
Note Added: 0017497 | |
| 2013-05-06 07:14 |
|
Summary | cannot rejoin +O channel on relink ifnot +o => kick split-riders from +i / +O / +A channels |
| 2013-06-26 02:15 | wolfwood | Note Added: 0017716 | |
| 2013-06-26 11:51 | syzop | Note Added: 0017717 | |
| 2013-06-27 01:48 | wolfwood | Note Added: 0017720 | |
| 2013-06-27 10:34 | syzop | Note Added: 0017721 | |
| 2013-06-27 10:34 | syzop | Summary | kick split-riders from +i / +O / +A channels => kick split-riders from +O / +A channels |
| 2014-03-14 01:14 | peterkingalexander | Issue cloned: 0004296 | |
| 2015-08-08 17:52 | syzop | Severity | minor => feature |
