View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003055 | unreal | ircd | public | 2006-09-05 06:43 | 2012-05-07 17:01 |
| Reporter | syzop | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | ALL | OS | ALL | OS Version | ALL |
| Product Version | 3.3-alpha0 | ||||
| Fixed in Version | 3.2.10-rc1 | ||||
| Summary | 0003055: Server-side MLOCK support | ||||
| Description | I'm tossing up a crazy idea.. Server-side MLOCK support. Services would inform the IRCd (on-netsynch, and on any MLOCK change) of the modes that are mlocked. For example: SOMEMLOCKCMD #chan sntlk This would mean the s/n/t/l/k modes may not be changed by users (not +, not -), this COULD mean that for example +sntl 55 is locked and that +k may never be set, or it COULD mean that +sntl 55 somekey is always set. For the IRCd it does not matter what it means (see next). No paramters would be given, since they are not needed... The MODE is set by services and then locked (or actually, reverse, since that's safest). *All* the IRCd does is check upon every -mode/+mode by a user, to see if he/she is allowed to change it. What this would do is fix race conditions, so that you can for example lock +Q and other people cannot -Q. Or for any other mode, really. Channel owners (+q) would still be able to override the locked modes. So would servers (and services). In short: services would still need to enforce the locked modes themself (eg: in case of another server merging [netsynch]), like now. But they will get rid of the user race conditions. Good / Bad? Opinions are welcome, especially by services coders. | ||||
| Additional Information | Memory-wise this would consume, in Unreal3.3*, one 64 bit var, so 8 bytes per channel. Which is 8K per 1000 channels. CPU-wise impact is hardly any. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| 3rd party modules | |||||
|
|
this sounds like a perfect answer to the problem, rather than " killing " someone for racing the modes. |
|
|
I really like this idea, and you even thought of everything (Channel owners (+q) would still be able to override the locked modes. So would servers (and services).) And since it would be for 3.3.* it wouldn't cause any incompatibilities :) |
|
|
partly disagree. server/services only. don't allow channel owners to do so. if they are able to change the mlock in services, then they have the right to do so, and should not override. |
|
|
i definetly don't agree with you there tabrisnet; what if services is down for some reason (its possible, and can sometimes be for hours at a time) ? then the channel owner can't even change mlocked modes.... |
|
|
and if you have multiple channel "owners" (who have +q), but only one is founder, and only one can change the mlock, what happens there? We now have a way for a co-founder, or non-founder, to bypass something the founder wanted! |
|
|
.... there comes the issue of who do u trust.... |
|
|
Which is often the entire point of +Q. Not trusting the ops to not war with each other. Yes, it shouldn't happen. It does. It happens in real life (assuming anything on IRC is real). |
|
|
ops maybe, but not channel owners (+q), which is what the thread was all about to begin with |
|
|
Also, I think when modes are locked on the channel, as with services, only the specified modes should be forced. To lock modes unset, simply specify the -mode as you would with services: nt-k Lock +nt, but do not allow +k All other modes should be settable |
|
|
Hi. I'm tabris, owner of SurrealChat.net. I have about 200 users, half of which are under the age of 14. Maybe 10% are over 20. Many of these kids are at the stage where mIRC is cool and scripting is leet. Writing or testing shitlist and war-scripts is a hobby of theirs. Now, to be honest, the founder should take care of this, and if they don't care then it's not an issue. But the fact remains, this does happen, it will happen, and it cannot be stopped short of closing/freezing the channel and removing all chanop status. Meanwhile, it is not uncommon for +Q to be set by the founder to prevent such chanop wars, but still allowing problem users who are NOT on the channel access list to be removed via !kick. Yes, You are assuming that users will either be smart or responsible. I'm not. I want a speedbump so 16 y/o Johnny doesn't run over any children in his new Jaguar going 40MPH in the parking lot of the nearby WalMart. I no longer believe in hte goodness of others. At least not of little children when dealing with other little children. |
|
|
As to services being down... if services is down [long enough], NO ONE will have +q, as no one will be able to ask chanserv to op them. |
|
|
IMO +q should be allowed to change it (well and opers with can_override of course, and SAMODE etc, but needless to say that) But, anyway, as for when services are down.. that's a good point. I think it should be made that, when services (server defined in set::services-server) are down for more than a certain period of time, then all server-side MLOCKing restrictions should be removed (remove the restriction itself), this can even be made configurable in the unrealircd.conf, and default to - for example - 5 minutes. |
|
|
Then it will need to be something that is also kept and synched when a netsplit is resolved (I probably said that badly, but the only term I can think of is 'netsplit healing'). Services won't know to reset it otherwise. |
|
|
Yup (I understand). |
|
|
what happens if your server side mlock clashes with that of a services (uline) set mlock? Does the uline override the server side mode lock? Not referring to +q users here of course u:lines are a seperate issue, u:lines should NEVER be allowed to 'lose' at any attempt to do *anything*. |
|
|
Pretty obvious I think :P |
|
|
Don't U:Lines override pretty much everything anyhow? (Including the current form of server side mlock (restrict-channel-modes, or w/e)) |
|
|
Correct. |
|
|
In the even services go down, I think servers should keep the settings... If they are there, then they are wanted, and if they were temp, then there should still be a +q around to undo it |
|
|
I agree with Bugz, i don't really think it should be temp if services splits, could kind of defeat the purpose... and there would most likely still be a +q around |
|
|
As I said, the time limit would be configurable. |
|
|
charybdis recently introduced this feature. the way it works is that you just specify a list of modes that cannot be set on the channel and any modechanges done by a local client are cancelled. it's effective and it works quite well. at any rate, if you guys add a protoctl token for it, i'll add the integration bits in atheme :) |
|
|
unreal-mlock.patch implements this using the logic from charybdis. it assumes that services aren't going to be gone for a long time (which is a valid assumption for unreal networks). |
|
|
- Add support for server-enforced mode locks (MLOCK), suggested in 0003055 back in 2006. This allows the IRCd to enforce MLOCKs that are set by services, which eliminates clashes between users setting modes and services enforcing it's mlock on channels. http://hg.unrealircd.com/hg/unreal/rev/a4058e167586 http://hg.unrealircd.com/hg/unreal/rev/7788ade137c0 Thanks for the patch. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-09-05 06:43 | syzop | New Issue | |
| 2006-09-05 07:07 | White_Magic | Note Added: 0012318 | |
| 2006-09-07 21:31 | djGrrr | Note Added: 0012349 | |
| 2006-09-07 21:56 | tabrisnet | Note Added: 0012351 | |
| 2006-09-07 22:36 | djGrrr | Note Added: 0012352 | |
| 2006-09-07 22:43 | tabrisnet | Note Added: 0012353 | |
| 2006-09-07 22:45 | djGrrr | Note Added: 0012354 | |
| 2006-09-07 22:55 | tabrisnet | Note Added: 0012355 | |
| 2006-09-07 23:03 | djGrrr | Note Added: 0012356 | |
| 2006-09-07 23:05 | Stealth | Note Added: 0012357 | |
| 2006-09-07 23:26 | tabrisnet | Note Added: 0012358 | |
| 2006-09-08 08:37 | tabrisnet | Note Added: 0012361 | |
| 2006-09-08 08:47 | syzop | Note Added: 0012362 | |
| 2006-09-08 09:01 | tabrisnet | Note Added: 0012363 | |
| 2006-09-08 10:00 | syzop | Note Added: 0012364 | |
| 2006-09-09 08:14 | brain4 | Note Added: 0012369 | |
| 2006-09-09 09:06 | syzop | Note Added: 0012370 | |
| 2006-09-09 12:03 | JasonTik | Note Added: 0012371 | |
| 2006-09-09 13:01 | syzop | Note Added: 0012372 | |
| 2006-09-09 14:38 | Stealth | Note Added: 0012373 | |
| 2006-09-09 17:40 | djGrrr | Note Added: 0012374 | |
| 2006-09-09 17:55 | syzop | Note Added: 0012375 | |
| 2007-04-27 03:22 |
|
Status | new => acknowledged |
| 2010-07-14 21:25 | syzop | Relationship added | parent of 0003915 |
| 2010-11-17 19:52 |
|
Note Added: 0016433 | |
| 2012-03-25 23:50 |
|
File Added: unreal-mlock.patch | |
| 2012-03-25 23:51 |
|
Note Added: 0016963 | |
| 2012-03-25 23:51 |
|
Status | acknowledged => has patch |
| 2012-05-07 17:01 | syzop | Note Added: 0016994 | |
| 2012-05-07 17:01 | syzop | Status | has patch => resolved |
| 2012-05-07 17:01 | syzop | Fixed in Version | => 3.2.10-rc1 |
| 2012-05-07 17:01 | syzop | Resolution | open => fixed |
| 2012-05-07 17:01 | syzop | Assigned To | => syzop |
