View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004157 | unreal | ircd | public | 2013-01-09 04:08 | 2015-08-08 08:15 |
| Reporter | katsklaw | Assigned To | tmcarthur | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Target Version | 3.4-alpha3 | Fixed in Version | 3.4-beta2 | ||
| Summary | 0004157: config definable oper levels | ||||
| Description | Add config defined oper levels/classes along the same concept as charybdis or inspircd. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
If this is added then all of the oper-related user-modes aside from `o` (and s?) should be removed in favor of handling this with the internal permissions. |
|
|
Not really so. You can still use all the same flags and modes, define which class gets what :in the config file and not hard coded as it is currently. The admin flag would still get +A. Having config defined oper classes allows the user to choose what flags the "admin" oper class receives. Contextually, the admin flag would then be more of a vanity label than a set of permissions |
|
|
+1 ShawnSmith |
|
|
Do we only want people to (re)define what existing 'ranks' (netadmin etc.) can and cannot do? Or phrased differently: be able to define the default privileges you get with 'netadmin' etc. OR, Do we want people to freely define/create (new) ranks? I think that latter is what you guys suggest? I remember that when we removed techadmin (more than 10y ago) it sparked a big discussion about wanting it back and definable things. Since then though, I haven't heard much about it. There is a strong desire for more granularity in oper blocks with regards to what someone can and cannot do. That doesn't necessarily mean that there is also a need to define new ranks or groups, though, but there could be. Indeed, if you let people create new ranks, then how do they relate to user modes? If you really make it free then there may be no relationship at all. In the end the user modes may become more and more meaningless, especially when you improve the granularity of permissions in oper blocks (that probably isn't proper English...). For local servers the user mode may not be required for permission control, as we can just check individual permissions (oper flags). Other servers don't have this information (at the moment, that is, we can decide to broadcast it of course) Question is, do other servers need this information? Do services need this? Presumably services only need to care about +o or -o as the ircop has to logon to services anyway. When logged on services decide what a user can and cannot do (as far as services are concerned, that is). This leaves other servers, do they care if someone is a netadmin or if he is serveradmin? There could be a few places, the source would have to be checked. As said, if other servers (may) need this info, then we could always decide to broadcast it on oper-up. For a locally connected oper there are still a number of places (possibly even a lot) where we only check for IsNetAdmin() and such, and not for a specific operflag. If netadmin is removed, then these checks would have to be changed as well, and then I mean moved to a (new or existing) oper flag or permission control. Anyway, as you can see, this issue strongly relates to more control (granularity wrt permissions) in oper blocks, rather than 'only' being able to define/add levels. That is, IF you choose to scratch all user modes that indicate a rank/level. EDIT: Oh, and, of course the rank itself would need to be communicated some way. So you can for example have a channel mode where you filter on ranks. Like the old/current +N channels but then +whatever rank1,rank2,rank3 etc.. We really need to discuss this in detail before anything is changed :) |
|
|
@syzop point taken. I do like the idea of checking against flags versus modes. I can see that in many cases it would be as good or better. I think from the human aspect it is still desirable to mark an oper as an admin or whatever but as you mentioned, that can be done via swhois while freeing up a bunch of user modes. We can create custom oper classes in a config file as other ircds do and then perhaps add checks against classes or flags. This can go for channel access too. Edit: The channel access would work splendidly with 0004116 /chanprop #channel restricted admin (where admin is the name of an oper class) |
|
|
The way inspircd handles it, I think the class names are entirely there for vanity reasons. There is never a specific check for a class name outside of the /whois line. I think this is the way to go, checking for specific oper-permissions instead of a class would make the oper configuration incredibly flexible. |
|
|
Note: My post here is based on my understanding from the replies I got from the forums: http://forums.unrealircd.org/viewtopic.php?f=3&t=7647&sid=ac4d7555da61b79432eca0eb2270befa 1) I do not find it is necessary to have identical pre-defined oper rank with different names and different user modes as they do not do much other than for labelling purposes (i.e. admin is identical to coadmin, services-admin and netadmin). 2) Instead of cracking our heads and debating the right combinations of flags suitable for a particular rank, why not leave it to the users to define what is suitable for a certain rank; we just provide the examples in the config file. 3) I think three ranks should be fixed which are local, global and admin (users cannot change the name of these ranks) but users are allowed to add additional ranks. Users are free to edit flags of any rank. 4) With that in hand, the following user modes are not needed: a - Services Admin C - Co-Admin N - Network Administrator But the following user modes can still be used: O - Local IRC Operator o - Global IRC Operator A - Server Admin 5) With that in hand, there is no need to worry about these channel modes that filter ranks: A - Only Administrators may join O - Only IRCops may join 6) Each rank should come with a 'default' swhois which is editable. Probably we can make multiple 'default' swhois lines possible. 7) We should introduce 'inheritance' feature when defining flags for any ranks (I am seeing this in charybdis). 'Inheritance' means flags awarded to an inherited rank will be re-awarded, if defined, in the new rank. 8) I will write about giving ranks to user(s) soon. |
|
|
There is no need for any pre-defined ranks at all. I too am thinking Charybdis. If checks are against flags then the only mode needed is +o and that only for rfc compliance. As far as the operclass block, we can have all the same options that's current in the oper block but apply to the entire class. Swhois can be used to specify the opers "level". Think, *is a netadmin. Default snomasks, modes and even the oper auto-join value can be added which will add the ability to drop locops into help channels, globops into oper help channels and admins into any other channel. Chanmodes +OA can stay. +A can be checked against the flag. |
|
|
(I should probably check out charybdis before I write anything, and I probably have looked at inspircd once but don't recall ;p) Right. We can just have no ranks or levels. Everything is defined in the oper block. The only reason why you still might want to have some kind of definitions/ranks/levels/class/howeveryoucallit is so you can easily have multiple opers share the same set of permissions without writing a big oper block for each. That way, you don't need (or have) ranks at all, but you can still more or less get rank-like-behavior by simply defining multiple oper types (such as 'netadmin' and 'serveradmin') and use them in your oper blocks for individual users. Reading back, I think that is what 2 or 3 of the previous posters already said/meant :) I just wanted to say that I appreciate the input of all of you! (of course, feel free to post more if you feel you have more useful things to say ;p). |
|
|
(Not sure if this has been mentioned, but I am putting it here anyway) I don't think we should depreciate +o, as it is used as a single point of identification for scripts and services to detect someone being an oper or not. |
|
|
Yes, +o will definitely stay. For the exact reasons you mention :) |
|
|
Based from what I have been told, rank "local" gives umode +O and "global" gives umode +o. I think the current method of treating ranks as flags and vice versa is a bit confusing and needs to change to the following: For example, treat "local" as flags and include it with other flags in "locops" rank and such. Such way, we do not need any pre-defined ranks. Also, what should user mode +o represent after removing other user modes? And which flags is required to obtain user mode +o ? |
|
|
[Based on the docs] There are other commands and user modes that needs review if the current pre-defined ranks are to be removed. All sa* commands (requires services & network admins) Rehash [<server>|-global] (netadmin only) User mode +q (services admin only) |
|
|
Dboys, +O goes bye bye. +o will denote the user as an ircop and grants nothing at all. The opers privileges come from the flags that are set in the config for their operclass. Yes, cmds like/sa* will need to check for flags instead of user modes. Tomorrow is my day off so i will post a long example for what I'm imagining for this |
|
|
Got it. I have some examples in mind too. I would love to read your examples :) |
|
|
Grouped oper flags local, global, admin/coadmin, services-admin and netadmin go bye-bye. operclass helper { class clients; // same as oper::class but applies to everyone in this operclass flags { can_globops; get_host; helpop; }; tagline "is a Network Helper"; // sent as a 381 [required] vhost "helper.myirc.net"; // replaces set::hosts::* host-on-oper "yes"; // replaces set::hosts::host-on-oper-up operstats "yes"; // can user see oper only stats? // oper block overrides these. swhois "regular swhois"; snomask "kvSo"; modes "+wgs"; maxlogins "2"; }; operclass global { class opers; inherits "helper"; // we only inherit flags flags { can_wallops; can_globops; can_localroute; can_globalroute; can_localkill; can_globalkill; can_kline; can_unkline; can_localnotice; can_globalnotice; can_gkline; can_gzline; }; tagline "is an IRC Operator"; vhost "global.myirc.net"; host-on-oper "yes"; operstats "yes"; // oper block overrides these swhois "regular swhois"; snomask "kvSo"; modes "+owgs"; maxlogins "2"; }; As you can see, it's a dynamic system but still has Unreal's look and feel. |
|
|
^ +1 I like the idea of setting vhosts in operclass. Two questions though: 1) Which flags should be checked to determine if a user is an IRCop (for chmode +O purpose) 2) Which flags should be checked to determine if a user is an Admin (for chmode +A purpose) |
|
|
1> umode +o can still be checked. As mentioned above, umode +o must remain for both client/script/services purposes as well as it's RFC required. 2> we can have an admin flag that doesn't grant additional privileges. Currently the local/global/(co/net/services-)admin flags all assume additional priviledges, this feature will remove the assumption. There is no reason to keep any other grouped flags like (co/net/services-)admin. On a slightly off topic note, this feature will satisfy bug 0003683 as well. |
|
|
Oh and another question: Which flags should be checked to give user mode +o ? |
|
|
See operclass::modes in my example. It would work the same as the current oper::modes does. |
|
|
One thing that would be confusing is the: inherits "helper"; // we only inherit flags Your comment makes clear it would only inherit flags, but without the comment it would not be obvious. Perhaps it can be moved to flags?: operclass global { class opers; flags { inherits "helper"; // <- moved can_wallops; Looks a bit awkward on first sight, but that's just because I'm used to only seeing can_something; there ;). It would be much clearer this way, you can immediately see that only flags are inherited. EDIT: another way would be: operclass global { .. inerit-flags "helper"; EDIT: or just... make it inherit all, and not just flags ;) *** I would like to expand the discussion to flags itself: Currently there's: * level flags (admin, netadmin, etc) -- these would be removed in the plan * get_umodew and get_host, neither belongs in ::flags IMO! * helpop: this too is simply providing a user mode, shouldn't be here either. not to mention helpop may go bye-bye. * a lot of can_* flags So actually, only the can_* flags would still be there. As I mentioned in an earlier bugnote: [quote]For a locally connected oper there are still a number of places (possibly even a lot) where we only check for IsNetAdmin() and such, and not for a specific operflag. If netadmin is removed, then these checks would have to be changed as well, and then I mean moved to a (new or existing) oper flag or permission control.[/quote] It would be nice if someone goes through all these IsAdmin(), IsCoAdmin(), IsNetAdmin() etc. checks and tries to group/map them to new or existing privileges. That way we will know what new can_* flags (or whatever it will be called) would need to be added. Also, if (after that!) we see that all flags start with 'can_' then we could consider dropping the 'can_' if it no longer adds anything. Then the flags will just be called 'wallops', 'zline', 'gkline', 'override', and so on. But we'd have to check first to see what the new flags bring, perhaps they warrant a different prefix other than can_. nenolod would you be interested in checking this? making a list / trying to group these privileges? or someone else? I won't have time for it, that's for sure... remember, I just said making a list at this point, not committing a whole new system ;P. |
|
|
I'm ok with rm-rf helpops so long as i can still denote non-opered staff members in an automated fashion without relying on external sources, namely services. I disagree that helpers status is useless. Perhaps only the current implementation? I agree that get_* aren't exactly flags, but neither is "inherits" ;) Perhaps "inherit-flags" is less convoluted. |
|
|
My plan was basically to bring over the same thing charybdis and inspircd have, here. What charybdis does is this: we have a giant string of privileges, and it is manipulated like one would do in ircII or mIRC (i.e. "giant strings are lists"). It works fast enough and it's infinitely extendable (verses 32 or 64 flags max) The nomenclature presently used is 'inherits' in those other IRCds. I think that at least usermode +a should remain with +o because services can pick up on that. Helpers could be denoted simply by having an operclass with no privileges -- this is how it is done on freenode, for example. |
|
|
Re charybdis/inspircd (which I haven't seen): I think you are talking about the internals, how the IRCd stores the privileges in memory, right? That's fine too, but I was still more or less talking about how things should be structured in the config and what model to use. When we have that, I'm sure we can find an appropriate means to store it (and communicate it to others, if necessary). But first we'd need to get an idea of what privileges we want to provide, and with what granularity. After all, it makes a difference if we will have 20 privileges, or 100, and how they are structured :). To everyone: speaking of granularity: 1) do you feel that some flags should be split up into more separate flags or be more configurable? 2) should any current privileges that now come by default with 'being an oper' be moved to a separate flag? 3) privileges that currently come with any level above globop should already receive a new flag or be merged into existing ones, see my comment 0004157:0017425 ('it would be nice if someone'..). Example: right now we have can_kline and can_unkline, now can_unkline is given to everyone right now so right now it's quite useless. The question is: do we like such granularity? should it be moved to other commands as well? such as being able to remove GZLINE's but not to add ones? If so, would we want to call this gline / unkline, or should we rather make it like.. gline { remove; }; ..with a default of permitting remove+add. As mentioned in #1 there might be quite a number of commands someone want to limit. Perhaps go through /HELPOP ?OPERCMDS to see what needs to be added, and with what granularity/depth? OR (better?) should we just provide a general framework where you permit/deny commands? This is very easy to do at the command level and when I look at the inspircd wiki it looks like what they do. In addition to limiting on a command level we would still want to have some abstract flags, such as override. As you all can see by now, I'm looking for quite a complete overhaul of the existing system ;) There has been a constant amount of criticism about the lack of granularity of the oper privileges in UnrealIRCd, I think 'now' is the time to solve it. Note that 'flags' may no longer be an appropriate term once this is done. That's only a small detail that would need to be addressed. Also whether it should be split into 'commands' and 'flags' is an option, but OTOH may lead to confusion if you want to do things like gline { remove; }; (is it a flag? or a command?). Again, it would be nice if someone could take this job. You don't even have to be some great coder to do it (but you will probably have to look at the source in some cases). If anything I wrote is unclear, do let me know. I look forward to seeing what kind of ideas you all have! :) |
|
|
Personally I would just like to see a separate privilege for using the spamfilter, I think its just a bit too powerful to bundle it into can_gkline. |
|
|
Yup, I agree. |
|
|
While the new oper permission system is not out yet, I took the opportunity to have a look at the current oper permission system. 1) Oper flag `locop` (l) is not mentioned in the docs although it is a valid flag according to *s_conf.c* and *m_oper.c*. `locop` flag is enabled by default in `local` flag. 2) If oper is not given `global`, `netadmin`, `admin`, `coadmin` or `services-admin` flag, they are automatically given `UMODE_LOCOP`. 3) If oper has all `local`, `global`, `netadmin`, `admin`, `coadmin` or `services-admin` flags (not very smart of them), their hosts will be set according to the host of highest privilege (netadmin) and they will be marked as a netadmin although they have umodes for all flags they have. 4) For some odd reason, `services-admin` does not have an `admin` flag. This disables them from using ADMINCHAT. 5) I propose a small change in `struct.h` and `m_oper.c` to remove potentially confusing overlapping use of `admin` and `services-admin` flags which will reflect in the docs. |
|
|
tmcarthur is working on a major rewrite, based on an idea + specification I came up with over a year ago. it should be in soon (a start of it, anyway) and is a release goal for alpha3. thanks for the notes though, could still contain some useful bits. |
|
|
4) For some odd reason, `services-admin` does not have an `admin` flag. This disables them from using ADMINCHAT. Services Admin is a services mode/flag, it's literally a "services admin", not a server admin. It's for use in conjunction with services based oper privileges, technically it's not an ircd oper level even though it's controlled via the /oper command. It only grants umode +a and a vanity /whois output. Therefore it shouldn't have /adminchat access. There are only 3 ircd admin positions, co-admin, admin, and netadmin. |
|
|
Heero is working on finishing off the operclass system. Since oper levels are then meaningless it's logical to remove them. As mentioned in a comment before we will keep +o but other than that these will be removed: N = Is a Network Administrator a = Is a Services Administrator A = Is a Server Administrator C = Is a Co Administrator So these user modes will be removed. And all IsAdmin(), IsCoAdmin(), IsNetAdmin(), IsSkoAdmin() calls will be removed. This also impacts the following channel mode as well: A = Server/Net Admin only channel (settable by Admins) (Just the one, as +O can stay as-is) So then we have the following: * each oper has a name * each oper belongs to an operclass * may have a free-text swhois Do we also include a 'rank' or 'level', like a word to denote a group of opers? Or do we just use the operclass name? In any case, a rank/level could be useful (even if we make rank==operclass) in: * /WHOIS: though swhois would be used, it would be nice to display some more detailed information about what kind of oper (at least to ircops) * Extban/extinvex: since +A will be removed we could make an +I ~O:name_of_level to create certain ircop level/rank only channels. * Services: 3rd parties may find the information interesting as well, like being able to require the class "netadmin" for some functions (though one could also argue this should be a services-side maintained list). Obviously communicate this information to the other servers. So... just thinking out loud, using 'operclass' directly versus a separate 'rank' statement (both are one single word only)....: Benefits of operclass directly: * Simple * It's clear what operclass privileges someone has (or at least if you keep your operclass blocks consistent accross servers, something that is recommended on any network to avoid confusion, eg by use of remote includes) Benefits of using a rank: * Could have different opers with different operclasses still have the same "rank", eg one low privileged bot may use KILL and another may use only SHUN, still call them both "bot". Downsides of using a rank: * Rank doesn't directly indicate privileges, you can keep the rank at "low-privileged-bot" but still put the person in the "netadmin" operclass I'm leaning towards using the operclass directly, there's only limited use for a separate rank. Also saves us from needing to display both the rank and the operclass in /WHOIS, best to just display one (to ircops). EDIT: for the whois, extinvex and services examples make clear that these are still useful if we decide rank==operclass. |
|
|
+1 for the operclass use as rank. It's simple and dynamic. +1 for operclass being denoted in /whois output. +1 for extban/extinvex +beI ~O:operclass. By using +beI ~O:operclass instead of just +I, channels can be set up in an accept all or deny all fashion. for example: /mode #Admins +b ~O:helpers /mode #Admins +e ~O:netadmins /mode #Admins +I ~O:admins My turn to think out loud ;) Do we also want to extend class based allow/deny to user classes as well as denoted in a standard class block? Since opers will be in seperate classes we could also extban/extinvex user classes instead of the traditional +b *@host, which will ban everyone. With the extension into connection classes, we can forbid normal client classes and allow special client classes based on class block. To extend my above example: /mode #Admins +b ~O:clients /mode #Admins +b ~O:helpers /mode #Admins +e ~O:netadmins /mode #Admins +I ~O:admins This makes it so users and helpers are banned, netadmins are exempt and admins must have an invex. /mode #Staff +b ~O:clients (This inherently bans unprivileged users) |
|
|
Great :) As for mixing operclass with class, like.. make them share the same namespace. Hmm.. I don't know.. I don't find that very appealing. One could easily create another extban type for it, though. Don't know what Heero thinks. |
|
|
"One could easily create another extban type for it, though." Indeed. I was limiting examples to the topic at hand. |
|
|
My bias is to avoid user confusion and obey the principle of least surprise - and since class and over class are entirely orthogonal it would be confusion for them to be in same namespace in that way. I'm fine with creating a separate extban for them though - I just thing particularly with a new concept we need to be EXTREMELY careful not to confuse the users. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-01-09 04:08 | katsklaw | New Issue | |
| 2013-01-09 13:51 | ShawnSmith | Note Added: 0017340 | |
| 2013-01-09 15:03 | katsklaw | Note Added: 0017342 | |
| 2013-01-14 11:58 |
|
Note Added: 0017367 | |
| 2013-01-14 14:38 | syzop | Note Added: 0017371 | |
| 2013-01-14 14:40 | syzop | Status | new => feedback |
| 2013-01-14 14:43 | syzop | Note Edited: 0017371 | |
| 2013-01-14 14:43 | syzop | Note Edited: 0017371 | |
| 2013-01-14 21:41 | katsklaw | Note Added: 0017376 | |
| 2013-01-14 21:46 | katsklaw | Note Edited: 0017376 | |
| 2013-01-14 21:47 | katsklaw | Note Edited: 0017376 | |
| 2013-01-21 22:55 | ShawnSmith | Note Added: 0017384 | |
| 2013-01-29 18:43 | dboyz | Note Added: 0017392 | |
| 2013-01-29 21:44 | katsklaw | Note Added: 0017393 | |
| 2013-01-30 00:05 | syzop | Note Added: 0017394 | |
| 2013-01-30 00:06 | syzop | Note Edited: 0017394 | |
| 2013-01-30 00:27 | Stealth | Note Added: 0017395 | |
| 2013-01-30 02:35 | syzop | Note Added: 0017396 | |
| 2013-01-30 03:43 | dboyz | Note Added: 0017398 | |
| 2013-01-30 04:53 | dboyz | Note Added: 0017399 | |
| 2013-01-30 04:58 | katsklaw | Note Added: 0017400 | |
| 2013-01-30 05:05 | dboyz | Note Added: 0017401 | |
| 2013-01-30 23:16 | katsklaw | Note Added: 0017406 | |
| 2013-01-30 23:18 | katsklaw | Note Edited: 0017406 | |
| 2013-01-31 05:07 | dboyz | Note Added: 0017408 | |
| 2013-01-31 19:14 | katsklaw | Note Added: 0017409 | |
| 2013-02-01 03:03 | dboyz | Note Added: 0017410 | |
| 2013-02-01 03:08 | katsklaw | Note Added: 0017411 | |
| 2013-02-01 03:10 | katsklaw | Note Edited: 0017411 | |
| 2013-02-01 03:13 | katsklaw | Note Edited: 0017411 | |
| 2013-02-12 06:44 | dummy | Status | feedback => has patch |
| 2013-02-19 22:24 | syzop | Status | has patch => feedback |
| 2013-02-19 22:36 | syzop | Note Added: 0017425 | |
| 2013-02-19 22:39 | syzop | Note Edited: 0017425 | |
| 2013-02-19 22:40 | syzop | Note Edited: 0017425 | |
| 2013-02-20 00:03 | katsklaw | Note Added: 0017427 | |
| 2013-02-22 09:23 |
|
Note Added: 0017434 | |
| 2013-02-22 10:39 | syzop | Note Added: 0017438 | |
| 2013-04-11 17:35 | wolfwood | Note Added: 0017475 | |
| 2013-05-21 21:37 | syzop | Note Added: 0017654 | |
| 2013-05-23 09:50 |
|
Relationship added | parent of 0002779 |
| 2014-06-08 19:55 | syzop | Assigned To | => syzop |
| 2014-06-08 19:55 | syzop | Status | feedback => assigned |
| 2015-05-19 05:39 | dboyz | Note Added: 0018319 | |
| 2015-05-21 19:54 | syzop | Note Added: 0018326 | |
| 2015-05-21 19:59 | syzop | Target Version | => 3.4-alpha3 |
| 2015-05-25 18:05 | katsklaw | Note Added: 0018345 | |
| 2015-06-15 12:59 | syzop | Note Added: 0018394 | |
| 2015-06-15 13:01 | syzop | Note Edited: 0018394 | |
| 2015-06-15 14:35 | katsklaw | Note Added: 0018395 | |
| 2015-06-15 14:50 | katsklaw | Note Edited: 0018395 | |
| 2015-06-15 17:22 | syzop | Note Added: 0018398 | |
| 2015-06-15 19:25 | katsklaw | Note Added: 0018401 | |
| 2015-06-16 15:22 | tmcarthur | Note Added: 0018403 | |
| 2015-08-08 08:14 | syzop | Status | assigned => resolved |
| 2015-08-08 08:14 | syzop | Fixed in Version | => 3.4-beta2 |
| 2015-08-08 08:14 | syzop | Resolution | open => fixed |
| 2015-08-08 08:14 | syzop | Assigned To | syzop => tmcarthur |
