multi: bake super macaroon during stateless init mode #844
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Which will result in a specific URL returning `true` for `IsWhiteListedURL` while still returning the original permissions in `URIPermissions`. This will be used for situations where we want to explicitly handle the verification of a call to a URL in a code path that happens after path that hits `IsWhiteListed`.
a type which implements the macaroons.MacaroonValidator interface which purely authenticates a call against LiT's macaroon service. Then, make this available to the rpc proxy. It is not used yet.
So that we have control over which LND client the rpcProxy should use for various calls.
so that we can use it elsewhere.
So that it is easy to check elsewhere if we are in this mode.
In this commit, we force the permissions manager to see the
BakeSuperMacaroon call of LiT as whitelisted. This means that when the
initial call comes in, the `LightningTerminal.ValidateMacaroon` method
will return early and not validate the call (which would fail in
stateless init mode since LiT does not have a macaroon service in that
case). So the call ends up going through to the rpcProxy's
BakeSuperMacaroon method. Here we now have the following flow:
- if the request does not have stateless_init set, then we keep the flow
as it was:
1) Use the lit mac validator to check that the call is allowed
given the required permissions of `BakeSuperMacaroon`.
2) if it is, then use the existing connection to LND that Lit
has to do the macaroon baking call.
- if stateless_init mode is set, then we do the following:
1) we extract the macaroon from the call (this should be an LND
macaroon)
2) we create a new connection to LND using this provided
macaroon.
3) use this connection to LND to bake the macaroon.
ellemouton
force-pushed
the
bakeSuperMacInStateless
branch
from
e6678ae to
ad0336a
Compare
|
will work on an itest for this 👍 |
|
@guggero: review reminder |
|
see #858 for an alternative approach 🙏 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds the ability to use LiT to bake a super macaroon during stateless init mode. What's nice about this is that the macaroon will also only contain all the permissions for the subservers activated. So for example, if Loop is disabled, then the super macaroon will not contain permissions for loop.
TODO: add an itest.
Usage
Let's assume LiT and LND are in stateless init mode & that the
admin.macaroongenerated during wallet creation is stored in~/mac_test/admin.macaroonlitclitrying to find LiT's macaroon & not being able to.Technical Detail
In this commit, we force the permissions manager to see the
BakeSuperMacaroon call of LiT as whitelisted. This means that when the
initial call comes in, the
LightningTerminal.ValidateMacaroonmethodwill return early and not validate the call (which would fail in
stateless init mode since LiT does not have a macaroon service in that
case). So the call ends up going through to the rpcProxy's
BakeSuperMacaroon method. Here we now have the following flow:
as it was:
1. Use the lit mac validator to check that the call is allowed
given the required permissions of
BakeSuperMacaroon.2. if it is, then use the existing connection to LND that Lit
has to do the macaroon baking call.
1. we extract the macaroon from the call (this should be an LND
macaroon)
2. we create a new connection to LND using this provided
macaroon.
3. use this connection to LND to bake the macaroon.