commit 35b6f4acce48315f0840e2ff9d4051245dd9a6cd
author Edwin Kempin <ekempin@google.com> Fri Feb 14 13:33:45 2020 +0100
committer Edwin Kempin <ekempin@google.com> Fri Oct 02 12:43:50 2020 +0200
tree a045a034e40c4da54bc3555e47f9c6a86b1785a7
parent f854f1897ee2c6536157d227c1cc5f9ba09011a1

CheckAccess: Return ACL debug logs

A very common support issue is helping users to find out which
permissions they are missing in order to perform a certain operation.

To let host admin investigate such issues the CheckAccess REST endpoint
has been added, however often it doesn't provide enough information for
host admins to understand why a permission is denied or allowed.

If a request is traced detailed information about which ACL rule
denied/granted the permission is available in the trace, but it requires
a server admin to look at the trace.

This change makes the logs that are relevant for ACLs available to
callers of the CheckAccess REST endpoint. It's okay to return these logs
from this REST endpoint since it requires the global Check Access
capability which should only be granted to trusted users (aka host
admins).

To make ACL logs available to the CheckAccess REST endpoint they are
collected in memory in the LoggingContext, similar to how the
LoggingContext stores performance logs. After triggering permission
checks, the CheckAccess REST endpoint can retrieve the ACL logs from the
LoggingContext and include them into the response to the client.

The collection of ACL log records is only enabled for the CheckAccess
REST endpoint, and is disabled for any other REST endpoint.

I tried to add a new method to the fluent logging API that allows to
send a log into the server logs and into the ACL logs at the same time,
e.g. logger.atFine().includeIntoAclLog().log(...) but it turned out that
this is not possible with Flogger (we can add new methods to the logging
API, but we have no access to the logged message to send it to the
LoggingContext). Anyway it turned out that for the permission checks the
message that we want to log in the server logs and the message that we
want to include into the ACL logs is slightly different, so that we
wouldn't have benefited much from such a new method in the logging API.

Change-Id: If82eb586272adecda445949989a314614cdd1072
Signed-off-by: Edwin Kempin <ekempin@google.com>