View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001844unrealircdpublic2004-05-30 20:312007-04-19 02:56
Reporteraquanight Assigned Tostskeeps 
PrioritynormalSeveritytrivialReproducibilityalways
Status resolvedResolutionduplicate 
PlatformX86OSWindowsOS VersionXP Professional
Product Version3.2 
Summary0001844: set::modes-on-oper causing unauthorized opers to get flag +q?
Descriptionoper LocOp {
    from {
        userhost *@*;
    }
    password "Blah";
    flags {
        local;
        get_host;
    };
};
set {
    modes-on-oper "+qgwhW";
};

-> OPER LocOp Blah
* LocOp sets mode: +wghOWqt

I did not give the oper can_setq, but it gets +q from the server anyway. Is it possible to make set::modes-on-oper respect the can_setq flag (or absence thereof)?
TagsNo tags attached.
3rd party modules

Relationships

duplicate of 0001899 resolvedcodemastr Add oper::usermodes 

Activities

codemastr

2004-05-31 01:25

reporter   ~0006477

If we do that, then there are many other things that follow. What if someone adds +N to the modes? Do we ignore +N for non netadmins?

aquanight

2004-05-31 12:01

reporter   ~0006482

Doesn't sound like a bad idea ;) .

Of course, the question that comes up is "Why put this mode in modes-on-oper?" And that's a good question, but what goes in there is most certainly up to the people that make the config ;) , and as it is, they can put any usermode in there... so maybe:
1) Don't allow any modeflag that depends on an operflag (+oOAaNq), or...
2) Only set flags an oper has permission to use. Any other flag is ignored.

Something like this would probably be needed for set::modes-on-connect as well if there isn't already something there ;) .

codemastr

2004-05-31 12:43

reporter   ~0006483

Well see I personally look to choice three:
3) Assume the admin has a brain

Almost no error checking is done for any of the mode settings. You could add +N to modes-on-connect if you wanted to! If an admin, for whatever reason, has decided all opers should be +q, why should I tell them they can't?

aquanight

2004-05-31 12:49

reporter   ~0006484

Well, yeah... ok...

Of course, said admin would probably also put can_setq in the oper blocks (so that the opers can set +q when they want it). Option #2 would allow him to exclude certain opers from this while still allowing permitted opers to get +q automatically (though maybe they should just not be lazy and set it themselves ;) ).

But, yeah, no error checking means need for smarter admins. But we can't assume every admin is smart, now can we?

codemastr

2004-05-31 13:04

reporter   ~0006485

No, but if you treat them like idiots, they will have reason to act like idiots.

aquanight

2004-06-03 21:36

reporter   ~0006566

>No, but if you treat them like idiots, they will have reason to act like idiots.
(that reminds of a quote I heard once... something along the lines of... "Build an idiot-proof system and someone will build a better idiot." ;) )

*ahem* But seriously...
So from what I understand, the admin should just have all opers can_setq to make it look "right", or not put +q in the modes-on-oper, if he doesn't want opers to get +q w/o permission (I'm not even going to start on SVSMODE, because when it comes to server vs. services, services always win ;) , and services know best anyway (or should).)

Hm... maybe an option for ./Config for this? So the admin can chose if he wants operflags enforced or the right to have whatever modes set on opers he wants? I dunno... giving opers can_setq can lead to abuse anyway, so... (but any oper privilege can be abused...)

aquanight

2004-07-22 14:46

reporter   ~0007220

Last edited: 2004-07-22 14:47

 0001899

I guess this can be closed now?

edited on: 2004-07-22 14:47

Issue History

Date Modified Username Field Change
2004-05-30 20:31 aquanight New Issue
2004-05-31 01:25 codemastr Note Added: 0006477
2004-05-31 12:01 aquanight Note Added: 0006482
2004-05-31 12:43 codemastr Note Added: 0006483
2004-05-31 12:49 aquanight Note Added: 0006484
2004-05-31 13:04 codemastr Note Added: 0006485
2004-06-03 21:36 aquanight Note Added: 0006566
2004-07-22 14:46 aquanight Note Added: 0007220
2004-07-22 14:47 aquanight Note Edited: 0007220
2007-04-19 02:56 stskeeps Relationship added duplicate of 0001899
2007-04-19 02:56 stskeeps Duplicate ID 0 => 1899
2007-04-19 02:56 stskeeps Status new => resolved
2007-04-19 02:56 stskeeps Resolution open => duplicate
2007-04-19 02:56 stskeeps Assigned To => stskeeps