ctubbsii commented on PR #5483: URL: https://github.com/apache/accumulo/pull/5483#issuecomment-2810432110
> I think that's not the case, and is likely a bug. I agree. I'll include that fix here. I didn't realize that canScan was overloaded and that this API was calling the one that didn't audit. That's definitely a bug. I was looking at the wrong one in AuditedSecurityOperation, so didn't catch that. > Doesn't the audit.log pose the same risk? Yes, but those risks can be managed independently. My goal isn't to eliminate the risk, but to ensure users are empowered to manage it. Adding what is essentially an audit message outside the audit logger breaks users ability to manage these risks on these granular boundaries. (But this assumes the audit logger is auditing these... which it currently isn't... as you've pointed out.) > If users wanted to mitigate this risk, wouldn't they turn the audit log off? That's one way to manage risk. More likely, though, you would just configure it differently... like put it on a different volume, or send to a remote aggregation service, or compress or rollover differently. > The audit log might be more useful if `denied` operations were logged at a higher level than `permitted` operations. For example, if `denied` were logged at `warn` and `permitted` logged at `info`, then the user could easily change the log level to reduce the noise in the audit log. Maybe not. I don't think log levels map well to auditing "importance". What's more important depends on what the auditor is looking for. Auditing unauthorized access attempts is very different than auditing who had access to a specific data set; which is more important in those cases seems opposite from one another. Child loggers to allow more granular logging control for these would be better than using log levels. Or users can just use filters today, or send audit logs to a database for later query, rather than try to do everything in the logging framework. In any case, changes to the audit logger is well outside the scope of this. My goal in removing the new info message is to try to align things to the current level of granularity (audit log vs. not audit log), not add more granularity for audit logs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
