View Issue Details

IDProjectCategoryView StatusLast Update
0003055unrealircdpublic2012-05-07 17:01
Reportersyzop Assigned Tosyzop  
Status resolvedResolutionfixed 
Product Version3.3-alpha0 
Fixed in Version3.2.10-rc1 
Summary0003055: Server-side MLOCK support
DescriptionI'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 InformationMemory-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.
TagsNo tags attached.
3rd party modules


parent of 0003915 resolvedsyzop Unreal3.2.10 TODO 
parent of 0004301 resolvedsyzop Unreal3.2.10 TODO 



2006-09-05 07:07

reporter   ~0012318

this sounds like a perfect answer to the problem, rather than " killing " someone for racing the modes.


2006-09-07 21:31

reporter   ~0012349

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


2006-09-07 21:56

reporter   ~0012351

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.


2006-09-07 22:36

reporter   ~0012352

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


2006-09-07 22:43

reporter   ~0012353

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!


2006-09-07 22:45

reporter   ~0012354

.... there comes the issue of who do u trust....


2006-09-07 22:55

reporter   ~0012355

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


2006-09-07 23:03

reporter   ~0012356

ops maybe, but not channel owners (+q), which is what the thread was all about to begin with


2006-09-07 23:05

reporter   ~0012357

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:

Lock +nt, but do not allow +k
All other modes should be settable


2006-09-07 23:26

reporter   ~0012358

Hi. I'm tabris, owner of 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.


2006-09-08 08:37

reporter   ~0012361

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.


2006-09-08 08:47

administrator   ~0012362

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.


2006-09-08 09:01

reporter   ~0012363

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.


2006-09-08 10:00

administrator   ~0012364

Yup (I understand).


2006-09-09 08:14

reporter   ~0012369

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


2006-09-09 09:06

administrator   ~0012370

Pretty obvious I think :P


2006-09-09 12:03

reporter   ~0012371

Don't U:Lines override pretty much everything anyhow? (Including the current form of server side mlock (restrict-channel-modes, or w/e))


2006-09-09 13:01

administrator   ~0012372



2006-09-09 14:38

reporter   ~0012373

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


2006-09-09 17:40

reporter   ~0012374

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


2006-09-09 17:55

administrator   ~0012375

As I said, the time limit would be configurable.


2010-11-17 19:52

reporter   ~0016433

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


2012-03-25 23:50


unreal-mlock.patch (8,589 bytes)


2012-03-25 23:51

reporter   ~0016963

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


2012-05-07 17:01

administrator   ~0016994

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

Thanks for the patch.

Issue History

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 stskeeps Status new => acknowledged
2010-07-14 21:25 syzop Relationship added parent of 0003915
2010-11-17 19:52 nenotopia Note Added: 0016433
2012-03-25 23:50 nenolod File Added: unreal-mlock.patch
2012-03-25 23:51 nenolod Note Added: 0016963
2012-03-25 23:51 nenolod 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