Closed guggero closed 2 years ago
Looking into this :)
Want to follow up here with some more details of a new approach I've been discussing with Graham from voltage in the background.
This applies primarily to a stateless init mode for LiT, where lnd
is running in an integrated mode. When lnd
is integrated, rather than doing the normal TLS+Macaroon stuff as is, we can instead just use a bufconn in place of the normal RPC connections. This lets us not have to deal w/ TLS certs internally, and it's kind of redundant, given everything is already running in the same memory space.
Next up macaroons, we'll still need them unless we want to disable macaroons all together for the stateless init mode. Given that everything is in the same memory space, we can actually just have lnd
re generate the admin macaroon on start up (via the bakery), then pass that using an in-memory channel over to the main LiT initialization logic.
lnd
has been unlocked, but we haven't yet fully initialized the RPC proxy and LiT web server. lnd
always send one for unlock, or we get it from some other external source. With the above, when running in stateless init mode w/ an integrated lnd
mode, no special configuration or macaroon+TLS cert passing is needed. We instead just pass macaroons over to LiT in memory, and everything else should work as expected.
For a mode where lnd is remote, but everything else is integrated, we'd follow the route of the user making a "super macaroon" from lnd
, and passing that over config or CLI to LiT.
In terms of the relevant areas to execute the plan for a fully integrated lnd
mode, here're some relevant areas:
dialBackend
function: https://github.com/lightninglabs/lightning-terminal/blob/master/rpc_proxy.go#L434
grpc.Dial
here, we'd instead use the bufconn
here in-place. No TLS credentials are needed as it's all happening in-memory.
readMacaroon
function: https://github.com/lightninglabs/lightning-terminal/blob/master/rpc_proxy.go#L467Finally, lnd
itself needs to have a set of bufconn
listeners that it uses in order to receive these in-memory RPC requests, but still retain its normal external RPC listeners. We can likely leverage all the existing falafel
infra that takes protos and generates stubs that terminate using the bufconn
connections.
Thanks for writing this out @Roasbeef. At a high level this makes sense, just a few clarification questions.
lnd re generate the admin macaroon on start up (via the bakery),
I'm not exactly familiar with this process. Does it create a new admin.macaroon every time or just regenerate the same, existing one? Mainly concerned about bloating the macaroon DB
One question here is "where do we get the macaroon from"? We could either have lnd always send one for unlock, or we get it from some other external source.
Say we went with the lnd always send one for unlock
method, how would this work in practice? If we're unlocking LND in the same way it exists today (via API), how would LiT get that admin.macaroon passed into it to then start up Loop, Pool, and Faraday?
For a mode where lnd is remote, but everything else is integrated, we'd follow the route of the user making a "super macaroon" from lnd, and passing that over config or CLI to LiT.
Wouldn't the super admin macaroon be needed in both scenarios? A user would have to use it to authenticate to the Pool or Loop APIs if they wanted to use those. A user would bake a super-admin macaroon in LND then use it to authenticate to Pool if they wanted to hit that API externally. Pool would then would call to LND to validate the macaroon in the request. Here I'm assuming that the LiT UI doesn't need the macaroon to Pool to work. If it does then the user would have to input the macaroon into the LiT UI or something...
While typing this I had an idea. What if this was the flow in integrated
mode:
Edit:
Thinking about this even more; Seems like in this setup we'd still have just two types to run LiT, integrated
and remote
and either one could be ran as stateless
. When running in integrated-stateless, the above changes apply. However when running in remote-stateless, there needs to be a way for LiT to accept an admin macaroon from the user. Perhaps instead of the password field we let them input an admin macaroon for LND. Once input, LiT still bakes the super macaroon like normal but then connects via standard TCP to the remote LND node.
I'm not exactly familiar with this process. Does it create a new admin.macaroon every time or just regenerate the same, existing one? Mainly concerned about bloating the macaroon DB
So it would just re-create it from scratch, no extra DB persistence needed. What we store is the root macaroon key, which can be used to derive any macaroon.
Say we went with the lnd always send one for unlock method, how would this work in practice?
So it would either send it over the RPC response (kinda like what happens in the stateliness init mode), or it would expose a new package-level method to access it. This would only be accessible if things are running in the same memory space, which they are when the integrated mode is set up (lnd
as a package): https://github.com/lightninglabs/lightning-terminal/blob/master/terminal.go#L187
If you follow that link, you'll see that ordering wise, we always start up lnd
, then start up all the other sub-systems as they rely on lnd
already being active before they can start to communicate w/ it. The startSubservers
method is where all the other components are spun up, once again just "importing" them as they've been made to be able to function as standalone packages.
Wouldn't the super admin macaroon be needed in both scenarios? A user would have to use it to authenticate to the Pool or Loop APIs if they wanted to use those.
Yeah in terms of them interacting with things on the command line, or via some other interface, you're right. As far as the current LiT UI, what ends up happening is that we catch the request, then actually read the macaroon on disk, to eventually ask each of the relevant sub-systems to validate it.
In the world of the "super macaroon", though, it wouldn't need to ask each sub-system, as lnd
offers the ability to handle auth for each of them.
Cool stuff @Roasbeef . I've been think about this and just have a couple questions on implementation.
So adding the bufconn listeners to lnd is already supported? We just add a new RPCListener? And I just want to make sure I understand why you mentioned Falafel - we can pass in the listeners the same way that's done with Falafel essentially?
Goal
It should be possible to run LiT in a way that it requires no sensitive information to be available to it on disk and also does not store sensitive information to disk itself. To enter that "stateless remote mode", I'd like to start LiT with just one flag:
--lnd-mode=stateless-remote
This would just start the UI and then wait for user interaction there. In this mode, the UI would not ask for a password first but for a
lndconnect
format connection string. The connection string contains all information that is needed to connect to the remotelnd
mode (IP address, TLS cert if necessary and macaroon). Once the string is provided, the LiT binary connects to the givenlnd
node and starts the integrated daemons (Loop, Pool, Faraday).Challenges
lnd
. This was fixed in https://github.com/lightninglabs/lndclient/pull/19 but that fix hasn't been pulled into the daemons yet. We can even expand on that and make it possible to pass in a macaroon directly as a hex string instead of needing to pass a file name.lndclient
that then needs to be pulled into Pool, Loop, Faraday and LiT.stateless-remote
mode, the daemons wouldn't use their own macaroons (wouldn't even create a macaroon DB) but instead use the remotelnd
node to validate their macaroons.lnd
doesn't know, this requires a new RPC inlnd
that allows us to validate a macaroon without checking the permissions part of it.lnd
to not complain about permission pairs or URIs it doesn't know itself.lnd
and all daemons. Basically containing all permissions that exist of all the 4 daemons.lnd
's) internally.Steps to completion
CustomMacaroonHex
tolndclient
'sLndServicesConfig
.lndclient
version containing the above change.lnd
that adds a new RPC call to check external macaroon permissions, for exampleCheckMacaroonPermission
. The same PR should also add a new flag to theBakeMacaroon
RPC that allows specifying permission pairs or URIs thatlnd
doesn't know. The flag could be called--allow_external_permissions
.stateless-remote
mode to the LiT binary and its internal gRPC/REST proxy component. In this mode it wouldn't look for a password in theAuthorization
header field but expect anlndconnect
string there. If such a request comes in and the daemons weren't started yet, it would do so first before forwarding the request.stateless-remote
mode and act accordingly.