View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003475unrealircdpublic2007-07-22 02:492009-07-24 01:09
ReporterstskeepsAssigned Toaquanight  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionopen 
PlatformAllOSAllOS VersionAll
Product Version4.0-devel 
Summary0003475: Work on a proposal for U4 oper types that match our system more yet is more flexible
DescriptionInitial proposal: http://dev.unrealircd.com/unreal4:development:operstyle
Additional information in types: oper hosts
Overriding stuff in opers done through syntactic sugar: ie,

oper foo { type what { stuff-to-override }; }; -> type _anon_42 { inherit what; stuff-to-override; }; oper foo { type _anon_42; };

InspIRCd API items need to be discussed and how modules use oper types
TagsNo tags attached.
3rd party modules

Relationships

child of 0003417 closed TODO list for Unreal4.0 

Activities

aquanight

2007-07-22 10:34

reporter   ~0014546

I should probably point out that when I was writing that up, I was pretty much focusing on the permissions aspect. type {} was mostly unchanged (with the exception of making room for inheriting), so yes saying host "blah"; in there was intended to work the same way (but things like override {} should move to flag block). I could probably look around what modules add stuff to the flag/type/oper blocks and make a list of where those things would go with this method.

As for the overriding through anonymous types, one thing we'd have to watch out for is, iirc, the type name is used as their line in the RPL_WHOISOPER (so eg by your example, instead of "foo is a <what>", you get "foo is a anon 42" (!) unless we make an exception for this case, actually, see my bit below on how to solve this).

One other thing I've considered (actually sort of just came to me while I was typing all this), not using the type's name as our display string in whois. This way the type name can be kept to a simple identifier. Example:

type netadmin { display "Network Administrator"; }; etc.

As for inherit itself. I originally intended it to inherit only permissions from one type to another (which is why I had it in type::flags rather than right under type). But if we're to use it as part of our syntactic sugar to deal with anonymous types, then it'll need to inherit host, display, and everything, but of course, stuff that only have one value can override. In fact, this probably makes more sense than only inheriting flags.

I'll probably put together a revision to my proposal to include most of this.

eLement

2007-07-22 18:03

reporter   ~0014552

Here we are. Modules that interact with Oper information (Such as Type, or Block)
-- m_invisible - (oper type) uses a variable canquiet in opertype with value as "yes" or "no", no is the default :: http://inspircd.org/wiki/Modules/invisible

-- m_operlevels - (oper type) uses a variable named level which contains integer values. The purpose is to have the IRCd map out (via a list of integers) who has more power. Thus a level 1 IRCop cannot kill a level 3 IRCop. Thus reducing the ability for abuse. http://inspircd.org/wiki/Modules/operlevels

-- m_oper_hash - (oper block) allows you to hash your passwords (i.e. encrypt them). Uses one variable hash which contains hash type. Then you must enter your password hashed. http://inspircd.org/wiki/Modules/oper_hash

-- m_opermodes - (oper type) allows for the removal or adding of modes at time of operup. This uses the variable modes, and the values are character values with +s (for adding) or -s(for subtracting) modes. http://inspircd.org/wiki/Modules/opermodes

-- m_override - (oper type) allows you to set what a type of operator can override. uses the variable override with the values being flags. http://inspircd.org/wiki/Modules/override

I believe that's all, on the Wiki anyhow. If you have more add them please!

eLement

2007-07-22 18:05

reporter   ~0014553

Adding on. The 'Display "Network Administrator";' seems like a good idea to me.

stskeeps

2007-07-23 13:08

reporter   ~0014564

I got thinking.. if we start having oper types and such - should our parameterised +O be a number? as in, level? or should we imply in syntax somewhere that.. netadmin > admin; admin > oper; etc?

eLement

2007-07-23 13:45

reporter   ~0014565

I think we should use the operlevels system before us, with InspIRCd's module. With the custom type, who's to say if some IRC network uses none of the constants from U3. They could easily change the opers to this:
Local - Helper
Global - Network-Operator
Admin - Server-Operator
Services Admin - System Operator
NetAdmin - God.

And if you define in syntax...it'll defeat the purpose.

Hm. It would have to be researched on how their operlevel system works. I think it checks the levels in real time. So when command is executed...it compares the two integers. If the one executing the command is less than the one it's being used against...it disables it. I'll look through the module and see if I can understand the code.

Shining Phoenix

2007-07-23 19:14

reporter   ~0014570

Last edited: 2007-07-23 19:17

 I think replacing type with level in oper blocks is something to consider.
1. Assign level to an oper. This may include flags. (oper block)
2. You may set everything but flags in a level. (level block)
3. Set the levels required for flags. The "flags block" keeps all those flags and numbers in one place where you can find and compare them easily.
e.g.

oper Bob {
  ...
  level 200;
  flags {
    can_go_insane;
  };
  swhois "is a flaming idiot"; #Anything specified in the oper block overrides the value in the level and flags blocks.
  ...
};

level 200 { #Anything specified in a level block overrides the value in a lower level block.
  display "is a Services Administrator"; #If someone has level 201, and you didn't specify display in level 201 or their oper block, their display is "is a Services Administrator".
  swhois "can help with your nickname registration problems.";
};

flags {
  can_do_this 200;
  can_do_that 200;
  can_do_stuff 100;
};

Usermodes O, o, C, A, a and N would be replaced by usermode o which has a parameter which is a number.
Channel mode O would have a parameter which is a number. You can only set +O to your level or lower, ie a level 200 can't set +O 300.
Channel mode A would be removed.
Add /who +o number (Or some other letter if o is taken)

aquanight

2007-07-23 20:04

reporter   ~0014571

Last edited: 2007-07-23 20:06

 Going down that road will no doubt end up with us back where we were with u3. The whole point of insp's system is to not have an enforced one-tree hierarchy where every oper of level X or higher can do Y, even if it's not their job to do Y. I definately don't want to see mandatory "Local Oper" ... "Admin" ... "Network Admin" back.

No, read my proposal at 0003420, which I will re-iterate here. The basic idea is:

No matter what, you can have: /mode #chan +O <type1>,<type2>,etc ... a comma-seperated list of types to allow. We also have a privilege token something like misc { join-operchan; }, those with it can join a +O channel *no matter what*. If the type '*' is given anywhere, then all opers can join. If it's doable, this could be the default if someone sets +O without a param (requires hacking to support optional parameters). I can probably add more info on how this all can work to the proposal.

We introduce levels into the equation if and only if m_operlevels.so is loaded. Then we have two options:
- +O syntax is just: +O <level> (or list of types).
- Or, merge into type syntax, where you say something like: #<level>, any oper of that level or higher matches and can join. We could have +O use a hook, so modules can add other criteria (flags, specific commands/other privileges, operators on a specific server/set of servers, operators with a hashed password / using an ssl cert to login, you name it, implement requirements on a what an oper can restrict/allow).

Or we leave +O as-is, and let modules implement something. Then again, a module's implementing +O in the first place.

Issue History

Date Modified Username Field Change
2007-07-22 02:49 stskeeps New Issue
2007-07-22 02:49 stskeeps Status new => assigned
2007-07-22 02:49 stskeeps Assigned To => stskeeps
2007-07-22 02:49 stskeeps QA => Not touched yet by developer
2007-07-22 02:49 stskeeps U4: Need for upstream patch => No need for upstream InspIRCd patch
2007-07-22 02:49 stskeeps U4: Upstream notification of bug => U4-only issue
2007-07-22 02:49 stskeeps U4: Contributor working on this => eLement
2007-07-22 02:49 stskeeps Relationship added child of 0003417
2007-07-22 10:34 aquanight Note Added: 0014546
2007-07-22 17:28 aquanight Assigned To stskeeps => aquanight
2007-07-22 18:03 eLement Note Added: 0014552
2007-07-22 18:05 eLement Note Added: 0014553
2007-07-23 13:08 stskeeps Note Added: 0014564
2007-07-23 13:45 eLement Note Added: 0014565
2007-07-23 19:14 Shining Phoenix Note Added: 0014570
2007-07-23 19:15 Shining Phoenix Note Edited: 0014570
2007-07-23 19:17 Shining Phoenix Note Edited: 0014570
2007-07-23 20:04 aquanight Note Added: 0014571
2007-07-23 20:05 aquanight Note Edited: 0014571
2007-07-23 20:06 aquanight Note Edited: 0014571
2007-09-07 14:01 aquanight Description Updated
2009-07-24 01:09 Stealth Status assigned => closed