Add "stateless remote mode"
See original GitHub issueGoal
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 remote lnd
mode (IP address, TLS cert if necessary and macaroon). Once the string is provided, the LiT binary connects to the given lnd
node and starts the integrated daemons (Loop, Pool, Faraday).
Challenges
- Loop, Pool, Faraday (=“the daemons”) still require each subserver macaroon to be available as a file to connect to
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.- Needs a small change to
lndclient
that then needs to be pulled into Pool, Loop, Faraday and LiT.
- Needs a small change to
- The daemons don’t have a stateless init mode yet, meaning they’ll leave their own RPC macaroons laying around on the disk (unencrypted).
- When running in
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. - Because the macaroons for the daemons will contain permissions and/or RPC URIs that
lnd
doesn’t know, this requires a new RPC inlnd
that allows us to validate a macaroon without checking the permissions part of it. - When baking a macaroon, a new flag would be necessary to instruct
lnd
to not complain about permission pairs or URIs it doesn’t know itself. - Users of the stateless remote mode would need to bake a “super admin macaroon” that gives access to
lnd
and all daemons. Basically containing all permissions that exist of all the 4 daemons.
- When running in
- The daemons don’t have an unlock mechanism yet, meaning their macaroon DB is unencrypted (or to be precise: the encryption uses a default password).
- Would also be solved by turning off macaroons for the daemons in the stateless remote mode.
- LiT gives the user access to all RPCs with just a password. That Basic Auth mechanism is turned into a macaroon internally. But it means the LiT backend needs access to all daemon macaroons (and
lnd
’s) internally.- The UI password would be replaced completely with the connection string. That could be stored in the browser’s session storage by the UI scripts. The macaroon part could even be encrypted, causing the UI to ask for a password before using it. That way the encrypted string could also be stored in the longer term storage of the browser, effectively requiring the user to “log in” again after the browser is closed.
Steps to completion
- (1) Add new
CustomMacaroonHex
tolndclient
’sLndServicesConfig
. - (2) Update Loop, Pool, Faraday and LiT to use
lndclient
version containing the above change. - (3) Add PR to
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
. - (4) Add the new
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. - (5) Update the LiT UI code to detect the
stateless-remote
mode and act accordingly.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:5 (5 by maintainers)
Top Results From Across the Web
calling a stateless session bean from a remote client
Hi zslevi, for remote invocations it means your client is running on a different VM than the ejb container. You need to get...
Read more >error when getting a remote EJB stateless sessi...
Hello, I work in java and use JBOSS eap 6.2 I have an EJB client and try to use a remote stateless EJB...
Read more >Converting Stateless Hosts to Stateful Hosts
You can add physical storage to your stateless ESXi, convert them to stateful ESXi hosts, and add the hosts to a cluster that...
Read more >Accessing a stateless EJB from another instance of Glassfish
I have a web page (with a couple of JSPs and a couple of HttpServlets) running on one instance of Glassfish. On the...
Read more >Stateless Session Bean - JavaEE EJB JPA Tutorials #04
In this EJB Tutorial, we will code our Stateless Session Bean and access it in the Servlet. You will learn Remote Interface, Context...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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. Whenlnd
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#L434grpc.Dial
here, we’d instead use thebufconn
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 ofbufconn
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 existingfalafel
infra that takes protos and generates stubs that terminate using thebufconn
connections.Looking into this 😃