View Issue Details

IDProjectCategoryView StatusLast Update
0001397unrealircdpublic2004-01-17 19:31
ReporterXeRXeS Assigned Tocodemastr 
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Product Version3.2-beta19 
Summary0001397: Additional logging facilities (sa*, chg*)
DescriptionAdd 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 InformationI 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.
TagsNo tags attached.
Attached Files
diffs.rar (1,200 bytes)
AbuseLog.rar (116,181 bytes)
3rd party modules

Activities

codemastr

2003-11-29 17:40

reporter   ~0004170

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!"

XeRXeS

2003-11-29 18:09

reporter   ~0004171

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 :)

XeRXeS

2004-01-08 18:56

reporter   ~0004579

Last edited: 2004-01-08 23:04

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

codemastr

2004-01-17 19:31

reporter   ~0004709

Added in .2047

Issue History

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 codemastr 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 codemastr Status acknowledged => resolved
2004-01-17 19:31 codemastr Resolution open => fixed
2004-01-17 19:31 codemastr Assigned To => codemastr
2004-01-17 19:31 codemastr Note Added: 0004709