View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003413||unreal||ircd||public||2007-07-01 04:53||2015-08-08 17:42|
|Reporter||Shining Phoenix||Assigned To||syzop|
|Summary||0003413: A change to OperOverride|
|Description||Currently, an oper can use OperOverride without intending to, because it uses the normal commands. If OperOverride mode, topic, kick, invite, and join commands were made, an oper will only use OperOverride when they explicitly want to.|
"/ojoin #blah" would get you into #blah past b, i, etc.
"/oinvite bob #blah" would be equivalent to an op in #blah inviting bob, and channel modes i and V can't stop you from doing it.
The other three shouldn't need explaining.
|Tags||No tags attached.|
|3rd party modules|
Not exactly the best thing... Has huge potential for abuse...
> "/ojoin #blah" would get you into #blah past b, i, etc.
Try /sajoin... IIRC it does override most modes.
[quote]Not exactly the best thing... Has huge potential for abuse...[/quote]
As opposed to oper-override as it exists now, which has the same potential for intentional abuse, and a greater potential for accidental abuse? For example, especially with prefixes off, a can_override ircop with +o-qa cannot immediately see at a glance if another has +a or +q and thus shouldn't be touched. If he tried to -o or kick (people do those for the weirdest reasons), he would succeed anyway, but would possibly throw out an "OperOverride -- blah" spew that will get the admins wondering what he's up to. Only join, of all the overridable commands, has a safeguard from accidental overrides. mode, kick, and topic do not have such safeguards.
[quote]Try /sajoin... IIRC it does override most modes.[/quote]
There's a huge difference between sajoin and the proposed ojoin:
- sajoin requires service-admin, ojoin would require can_override as normal override-join does. (We could eliminate the self-invite requirement because you can't accidentally join past stuff with regular join.)
- sajoin allows forcing others to join (working like a combined invite+svsjoin in that regard), ojoin would not.
- ojoin can have requirements like: can't override +A, or can't override anything if +O or similar stuff, and it can respect other module override restrictions. sajoin need not pay any attention to them
I should note, most IRCds that I know of that have oper overriding capability follow this approach of using a seperate command, namely bahamut uses sajoin and samode (which don't do the same as unreal's), and ircu uses opmode (and presumably override-join would be you just opmode out everything that's blocking you). Those are the only two off the top of my head.
This would also massively simplify our operoverride code. I'm sure you can see why that would be desirable if you searched for operoverride on the bug tracker ;) .
We have /SAJOIN, /SAPART, /SAMODE, which can be used without OperOverride to walk through modes, part others and set modes.
We could add /SAKICK (even though it would be very similar to /SAPART) and /SATOPIC (then again, this seems rather over the top).
..for the reason as explained in this bugreport.
or we could just close this. The requirement of services-admin for the /SA commands and the issue of disabling OperOverride is no longer an issue in UnrealIRCd 3.4.
|2007-07-01 04:53||Shining Phoenix||New Issue|
|2007-07-01 11:21||Stealth||Note Added: 0014433|
|2007-07-01 18:54||aquanight||Note Added: 0014434|
|2015-07-13 22:47||syzop||Note Added: 0018498|
|2015-08-08 17:42||syzop||Assigned To||=> syzop|
|2015-08-08 17:42||syzop||Status||new => acknowledged|