View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001397 | unreal | ircd | public | 2003-11-29 06:35 | 2004-01-17 19:31 |
Reporter | XeRXeS | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | resolved | Resolution | fixed | ||
Product Version | 3.2-beta19 | ||||
Summary | 0001397: Additional logging facilities (sa*, chg*) | ||||
Description | Add two logging flags for the conf: LOG_SACMDS (sa-commands) and LOG_CHGCMDS (chg-commands), which log sajoin/sapart and chghost/chgname/chgident respectively. This would help to avoid any abuse of these commands, as even low level opers have access to the "chg" commands, so power hungry trial opers can be quickly identified. | ||||
Additional Information | I think this would be a useful addition to the IRCd, as it would ensure that there is no abuse of those (VERY abusable) commands, or at the very least allow any abuse to be identified quickly. It would take only a tiny code addition, and it would also not take up too many resources or space, as the flag is optional, and the commands are very infrequently used anyway. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
3rd party modules | |||||
|
I like the idea, just not sure the names sa-commands and chg-commands are the best. Reason is, say someone creates a module for a command /sakick. I'm sure we'll be getting emails saying "I have sa-command logging on but /sakick isn't logged!" |
|
Well those are just the headers I used for the version I had running on my test box, they're fairly flexable :) Besides, if it was an official module (or even a 3rd party module written by someone who knows about the IRCd structure and would want it logged under the sa commands flag) you could add logging for it, and if not, they should RTFM ;) People might expect the module to automatically log under that header, but if it's a 3rd party module and doesn't explicitly state so, it's a rather silly assumption. ;p I understand the risk of confusion though, and would be perfectly happy to see the actual flags renamed to something a little less ambiguous :) |
|
I've made a few different changes to the code. :) I've renamed the slightly ambiguous "sa-commands" flag to "sadmin-commands", so it's a bit more obvious as to what it's supposed to do :P I added a new function as well, which is the main reason for my update; the ability to log OperOverride stuff. All OperOveride functions are now loggable, under an "oper-override" flag in the conf. I think that it's best to have all of these commands at least *optionally* logged, so that people who have no screening process for new opers can keep tabs on the most abusive commands used on their servers/networks. I've attached a file (AbuseLog.rar) containing a unified diff (logging.diff) and the modified source files (if anyone prefers to look through the code that way) as well as a text file listing what files were changed, and the new logging flags. Don't know if it's everyone's thing, but works for me ;P edited on: 01-08-04 23:04 |
|
Added in .2047 |
Date Modified | Username | Field | Change |
---|---|---|---|
2003-11-29 06:35 | XeRXeS | New Issue | |
2003-11-29 06:35 | XeRXeS | File Added: diffs.rar | |
2003-11-29 15:54 | syzop | Status | new => acknowledged |
2003-11-29 15:54 | syzop | ETA | none => < 1 month |
2003-11-29 15:54 | syzop | Summary | Additional logging facilities => Additional logging facilities (sa*, chg*) |
2003-11-29 17:40 |
|
Note Added: 0004170 | |
2003-11-29 18:09 | XeRXeS | Note Added: 0004171 | |
2004-01-08 18:47 | XeRXeS | File Added: AbuseLog.rar | |
2004-01-08 18:56 | XeRXeS | Note Added: 0004579 | |
2004-01-08 21:10 | syzop | ETA | < 1 month => none |
2004-01-08 23:04 | XeRXeS | Note Edited: 0004579 | |
2004-01-17 19:31 |
|
Status | acknowledged => resolved |
2004-01-17 19:31 |
|
Resolution | open => fixed |
2004-01-17 19:31 |
|
Assigned To | => codemastr |
2004-01-17 19:31 |
|
Note Added: 0004709 |