Oper Flags and Commands

w00t · Post by **w00t** » Fri Jun 04, 2004 3:22 am

What is the point of flags +kK etc when merely by having +O or o etc etc you automatically get +kK?

And then, how do you say, give someone helpop, but deny them the ability to kill?

I understand trust should be enough, but the system just doesnt make sense...

codemastr · Post by **codemastr** » Fri Jun 04, 2004 3:40 am

locops do NOT get the K flag. The documentation makes that quite clear. It says you get can_localkill (k) not can_globalkill (K).

w00t · Post by **w00t** » Fri Jun 04, 2004 3:59 am

Whoa there.

Ok, since we have one server... that distinction escaped me.

but anyhow. The point remains, how can you remove such flags from an oper?

codemastr · Post by **codemastr** » Fri Jun 04, 2004 4:01 am

You can't, no one every claimed that you could. It is there so you can GIVE global kill access to a local oper.

aquanight · Post by **aquanight** » Fri Jun 04, 2004 4:22 am

Well, the ability to "deny" certain flags (even if they are included in another oper flag) would be nice to allow extra customization for the oper perms. For example, say you wanted an oper that could join +O channels, but couldn't /kill or /kline? The only way to allow them into +O is to give them local or global flag, which gives them /kill|/*line privileges, which isn't what you want (and I don't think there is still anyway to override +O short of SVSJOIN/SAJOIN). What to do?

w00t · Post by **w00t** » Fri Jun 04, 2004 4:27 am

Yes, exceedingly useful. However, would it be possible is another question. I have no idea how oper perms are applied, whether its just on oper-up or what, so who knows.

Another example would be to, say, declare "classes" of opers. So there could be a "helper" class that could chghost, sethost, chgname, setname, chgident, setident, dccdeny... etc but NOT kill (therefore allowing those with knowledge to do stuff, but NOT be tempted)

aquanight · Post by **aquanight** » Fri Jun 04, 2004 4:30 am

w00t wrote:...declare "classes" of opers...

Uh... that'd probably require a completely different oper system than what they use now. I wouldn't put bets on that 'til the next release at the earliest.

w00t · Post by **w00t** » Fri Jun 04, 2004 4:34 am

True, but a basic form is more possible... just sorta seeing if in the oper block it said flags "+ohHW-kK"; or something, NOT allowing them to kill.

Of course, I am no expert on Unreal internals, but it shouldnt be too hard..? (I'm not expecting this for a while, just throwing an idea around anyhow)

codemastr · Post by **codemastr** » Fri Jun 04, 2004 5:43 pm

What would be the point of an oper that can't kill?

jewles · Post by **jewles** » Fri Jun 04, 2004 6:40 pm

LoL.... sorta like just having the cool whois tag "... is an irc operator"

what is should say....

".... is an irc operator that can't do shit"

seriously thou, some people should consider thinking about what they are about to post before they do....

What I'd be impressed to see is a new operator system.... in which lower "class" operators can't kill higher ones.... for example: your typical local oper without the ability to kill an global oper, co-server admin not being able to kill a admin... and so on and so forth...

codemastr · Post by **codemastr** » Fri Jun 04, 2004 7:13 pm

Why should such a system exist? If I tell you "you are not allowed to /kill admins," and you do anyway, then you shouldn't be an oper anymore! If opers don't follow the rules, they are not good opers. I don't quite see why we should spend our time coding a system that really shouldn't be necessary. Opers need to follow the rules, simple as that. I mean what's next? "Operoverride will not let you kick, -vhoaq, or +b someone who is a higher oper level than they are"? If your opers don't listen to you when you tell them not to /kill someone, then they are the ones that need to be /killed.

jewles · Post by **jewles** » Fri Jun 04, 2004 9:08 pm

LoL @ codemastr

Guess microsoft has spoild me... I'm used to the ability to limit everyone and everything at any time....

But.... I was just saying why should a local administrator have the ability to kill a network administrator? and why should a global administrator have the ability to kill a services administrator... Out side of that, sure... you can remove the oper.... but it's still temptation exist.... who knows, maybe there would be better operators out there if they weren't tempted to kill other opers!

Okay I'm done with my ..... rants....

codemastr · Post by **codemastr** » Sat Jun 05, 2004 4:02 am

Well for a few reasons that I can think of.
1.) The more checks we add, the slower it becomes (more code needs to be executed).

2.) It allows you to weed out bad opers. If an oper does /kill a netadmin, you know to remove him. It allows you to see whether that "temptation" will lead that oper to be abusive, and to stop him before he has the chance.

3.) MIT once conducted a little example of this. I wish I could remember which book I read it in so I could give exact numbers. Back when the first MIT timesharing machine came online it had a command to shutdown the entire machine. Any user could use this command. But, when logging in, it gave you a warning that read something like "do not use the shutdown command." Over the years, people only used the command 3-4 times. Now, when MIT later switched over to a "secure" shutdown command, hackers began finding exploits to shut it down causing the server to be shutdown several hundred times. In essence, people found it more tempting when there was security than when there wasn't.

aquanight · Post by **aquanight** » Sat Jun 05, 2004 2:42 pm

Well, the problem as it is now is that giving, for example, the local flag automatically gives the operator the ability to local kill, send/see locops and globops (though they should be only able to send locops), send wallops, and use /connect, /squit, /kill, /kline, and /notice $. However, the admin might not want his local operators to use routing commands (for example, you might have services directly linked). Oh sure you can say, "don't use /connect or /squit or your o-line is gone," but there's a chance that some oper is still going to do it. And if, for example, he does /squit the services, it would be a pain to get it relinked (especially if no available admins have shell access to the services host, and let's assume that the services host admin doesn't want to/forgot to/can't set up a crontab). The admin(s) might not even want the possibility to exist, and the easiest way to do that is to not give them the routing privilege, but since it comes package-deal with the local flag, what can he do, besides just not give them the local flag, which he might want to give them?

The way I see it, being able to "remove" flags lets the admins better customize the operator hierarchy that they use on their network. For example, there can be "helpers" (helpop, maybe a few extra privs), "enforcers" (local minus routing), local opers, global enforcers (global minus routing), global opers, etc. They can use the SWhoIs to indicate the real level the oper has.

w00t · Post by **w00t** » Sun Jun 06, 2004 11:47 pm

Thanks aquanight, this is exactly what I would say if I could organise my thoughts to that point. Just look at some of the larger networks, they for example have operators with different charters. Enforcers, helpers, and routing team etc.

Why should these people have the ability to do things that they shouldnt?

Naturally codemastr, you also forget the element of curiosity-- "dont /squit services.netronet.org" "gee I wonder what happens if..."

People learn, but why should they have the ability to squit, etc unless they know/are charged to use it.

Emotion is another thing, someone could get worked up and split a net in two! Normally they might not do such a thing, but they may have had a bad day.

What I am saying is that there are reasons, both for and against.