Closed KoraggKnightWolf closed 5 years ago
That sounds like overkill and unneeded complexity. There isn't any real abuse that can be done with this other than real-time notifications of what can be seen in other ways. Most services commands are logged already, channels are visible in a /whois, etc. Set the command permissions and logger up to your needs and deal with your staff that attempt to "abuse" it.
The idea behind us employing this module was to only log lots of activity from specific indiduals (e.g. suspected bots/botnets, getting "own logs" if logs provided about abuse are questionable and to make sure not fake, etc) and it is restricted to just services roots in our case (two users, usually one is mentally present, and usage wouldn't be frequent of this module I hope). As we do not wish to log most services commands as overtime it would fill/clog the logs up bigtime this one was sought out to only have them for "filtered" cases. But I suppose as most do, as you said, log most/all activity anyway it would not be an issue and also limiting as it cannot cause "servere" damage (e.g. it does not restrict users entering or using services.) One thing I did forget to bring up: It is a bit hard to tell where the realname/gecos ends and where the action is described, Could this perhaps be changed (like with using bold or another sytlistic option perhaps? Other than that, Thank You for taking the time to address this issue and if the above mentioned situation cannot be changed, feel free to close this issue of course.
Regards,
Koragg
It would be useful if os_notify could have certain exceptions, at least for localhost (also the 127.0.0.1 and 0::1 IP addresses) and also services operators (perhaps it can fetch the hsst info from /ns info or even read out the host = "" part of services.conf?) to avoid services operators using this against each other or even against the network itself.
Regards,
Koragg