View Issue Details

IDProjectCategoryView StatusLast Update
0003702unrealircdpublic2015-08-08 17:52
ReporterBricker Assigned To 
Status acknowledgedResolutionopen 
Product Version3.2.9-RC1 
Summary0003702: kick split-riders from +O / +A channels
Descriptionbasically, 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...
TagsNo tags attached.
3rd party modules



2008-06-19 15:38

reporter   ~0015308

Last edited: 2008-06-19 15:41

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.


2008-06-19 16:07

reporter   ~0015309

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


2008-06-23 14:26

reporter   ~0015312

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


2008-08-10 18:40

administrator   ~0015360

Last edited: 2008-08-10 18:43

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.


2010-04-03 19:54

reporter   ~0016061



2010-07-14 17:20

administrator   ~0016170

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


2013-02-24 03:11

reporter   ~0017439

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


2013-05-06 07:14

reporter   ~0017497

i am updating the title of this to be more descriptive of what we intend to do.


2013-06-26 02:15

reporter   ~0017716

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


2013-06-26 11:51

administrator   ~0017717

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


2013-06-27 01:48

reporter   ~0017720

Thanks for clarifying that, the updated title was misleading. That's why I posted.


2013-06-27 10:34

administrator   ~0017721

Indeed. Changed.

Issue History

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 nenolod Note Added: 0017497
2013-05-06 07:14 nenolod 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