The existing logic was to ignore Forbidden errors when recursively
listing in favor of looking for downstream scopes with appropriate
permissions. The problem is that when there is actually no
authentication token at all, what comes back is an Unauthenticated
error. Therefore if you didn't have permissions on the ingress scope
(e.g. the default of `global`) but did downstream for the anonymous
user, you'd get back an error.
I don't think there's any security issue with doing this; the user could
always have simply started the search at a downstream scope to begin
with so nothing more is being revealed, this just fixes behavior to
match expectations in this case.
A test was added for one of the services; the code is exactly the same
across them. The reason that the existing tests that were added with the
output fields testing didn't catch this is that even though they were
specifying `u_anon` as the user, the disabled test context skipped the
logic that would return a 401 in this case. It turns out that fixing
this is very complicated because we don't have a great way in most tests
of defining grants to put onto the generated scopes, so even if a true
anonymous context was added each test would require the anonymous user
to have list permissions on whatever resource was under test, requiring
a lot of role and grant and principal finagling. This is probably a good
longer-term TODO but not one that seemed worth it for this fix.
Fixes ICU-2301
Although we document that this is allowed, and the ACL code handles it,
some of the validation code did not. This would cause a semi
intermittent problem because that validation code is used only in some
code paths; specifically we skip it (for now) to avoid erroring out on
some deprecated grant string formats when reading grants from the DB,
but we use it to error out when validating incoming grants.
* server: Add back controller shutdown on worker startup failure
This adds back the controller shutdown call on worker failure.
This was added in a15961e4 to address a panic discovered in testing, and
was mistakenly thought to be unnecessary. This, however, covers
multi-role scenarios where we have already started the controller, which
needs to be shut down gracefully if possible if we can't start the
worker.
A nil check has been added to ensure the panic does not resurface.
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
* updated dockerfile to support multi-arch; added new section in Make for multi-arch
* adding a line to changelog
* switching base image to hashicorp mirror
This is very useful when trying to write managed groups filters as you
can directly look at the structure of the claims for the accounts you're
trying to filter.
The output of the claims in text format on the CLI currently leaves
something to be desired. I started revamping some of the formatting
functions and it quickly got very fragile. Fundamentally at this point
we're likely better off -- now that we have a good idea what our output
format/standards are like -- rewriting the formatting code. I'll take
that as a tasker as I have a lot of ideas...
This commit adds some rudimentary functionality for cleaning up
connections on controller failure, or more specifically, a failure to
communicate with the controllers.
In this scenario, when a status cannot be sent for any reason for longer
than 30 seconds, the worker will close all connections that are normally
not cleaned up (so for sessions that currently are *not* in the progress
of being canceled or terminated). Status requests now time out after 10
seconds if they are not made successfully.
Session status is not touched during this process, but natural cleanup
or connectionless sessions will still occur. This should be okay, as the
session should be added on re-connect if need be.
A few other changes are made to cancelConnections: first, error logging
has been moved to the function so that we can handle errors requesting
cancellation directly within the function; this entails simply just
locally marking these connections as closed with a warning. Second,
there was a minor logging bug where closed connections were not properly
being noted in the last trace log, this has been fixed.
Additional changes:
* Circle: Set acceptance test no_output_timeout to 30m
This ensures that cors_allowed_origins can be set when cors_enabled is
not explicitly specified and allowed to be its default (currently true).
The current behavior is to clobber this value when cors_enabled is not
explicitly set, ultimately setting it to the default of
"serve://boundary" only.