View Issue Details

IDProjectCategoryView StatusLast Update
0003413unrealircdpublic2015-08-08 17:42
ReporterShining Phoenix Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityalways
Status acknowledgedResolutionopen 
Platformi386OSLinuxOS Version2.6.10-1.771_FC2
Product Version3.2.6 
Summary0003413: A change to OperOverride
DescriptionCurrently, 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.
e.g.
"/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.
TagsNo tags attached.
3rd party modules

Activities

Stealth

2007-07-01 11:21

reporter   ~0014433

Not exactly the best thing... Has huge potential for abuse...

BTW
> "/ojoin #blah" would get you into #blah past b, i, etc.
Try /sajoin... IIRC it does override most modes.

aquanight

2007-07-01 18:54

reporter   ~0014434

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

syzop

2015-07-13 22:47

administrator   ~0018498

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

Issue History

Date Modified Username Field Change
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