View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004054 | unreal | ircd | public | 2011-11-20 20:17 | 2023-03-19 12:17 |
| Reporter | katsklaw | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Summary | 0004054: [feature] Make oper data/blocks more dynamic | ||||
| Description | This feature would allow for opers to save/change their own oper block data via IRC. Admins (oflag +A, optionally +N) can change other opers data, otherwise opers may only change their own with the exception of swhois, flags and maybe userhost for security reasons. Examples: Change oper password: /setoper katsklaw chpass old_pass new pass Change oper SNOMasks: /setoper katsklaw snomask +cFj Change oper flags: /setoper katsklaw flags -O+AaN As far as persistence across sessions, we would have to save the data to a flat file not unlike ircd.tune. Advantages: - Passwords can automagiclly be hashed so no more plain password storage. - No need for admins to have/use shell access. - No need to rehash after changes. - Allows other data to be easily added later such as notes on the oper (Think Anope's OINFO) and perhaps a "suspended" toggle for use with the ever elusive rogue oper or inactive/on vacation oper, password expiry .. etc. - Pro/Demotions are easier. - Allows for other oper data to be collected and displayed, such as last used date/time (think /ns info). Disadvantages: - Serious problems can arise if an Admin's account is compromised. Caveats: - Main or Root Admin accounts would need to be "hard coded" so at least 1 person has constant access. - Propagation would still require the oper to "deoper" then /oper again for changes to take affect. To carry this further as an compile option (with compile flag so it can be blocked), remote oper block manipulation. This could allow NA's to add/del oper blocks if said network policies allow. Speaking of network policies, the addition of a set::oper-data block could be added to configure what data can(not) be changed by the oper via IRC. Example: set { oper-data { password "yes"; flags "no"; snomasks "yes"; modes "yes"; }; }; | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
An additional advantage would be to be easier for modules to add their own oper flags. Also, something like this has been done before as a module, in AngryWolf's "opers" module. The module has been broken for quite some time, but also added the ability for opers to be added/changed across the whole network. Perhaps this feature may be better off as a revisit to the "opers" module. Shouldn't be too difficult to either fix the existing code or to create a new module based off what has already been written. |
|
|
granted a module would be nice. However, if this was in the core, it would ve the only ircd, at least that I'm aware of, that has this feature. If this feature works out well, it could be but a precursor to other features using the same framework for example, link blocks. |
|
|
Was going through old issues... I don't think this type of dynamic configuration is something we are currently after so I'm closing this. Something related could be used: the SVSO command allows granting specific IRCOp rights and stuff. This could be used from like a services package. Downside? What if services are down ;D https://www.unrealircd.org/docs/Server_protocol:SVSO_command |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-11-20 20:17 | katsklaw | New Issue | |
| 2011-11-20 21:20 | Stealth | Note Added: 0016793 | |
| 2011-11-20 21:49 | katsklaw | Note Added: 0016795 | |
| 2023-03-19 12:17 | syzop | Assigned To | => syzop |
| 2023-03-19 12:17 | syzop | Status | new => closed |
| 2023-03-19 12:17 | syzop | Resolution | open => no change required |
| 2023-03-19 12:17 | syzop | Note Added: 0022792 | |
| 2023-03-19 12:17 | syzop | Note Edited: 0022792 |
