lncli: add command to delegate macaroons

[guggero]

This PR addresses #283 and introduces the new command delegatemacaroon to the lncli tool.

Currently, this just exposes the functionality that the lncli already uses internally to the command line interface:

• Take an existing macaroon (by specifying --macaroonpath, default is ~/.lnd/admin.macaroon)
• [optional] Add a timeout to it (by specifying --timeout)
• [optional] Restrict it to a specific IP address (by specifying --ip_address)

Depending on the --format parameter, the following output is produced (truncated for brevity):

lncli delegatemacaroon --format=json --timeout=3600 --ip_address=123.123.123.123:

{
        "c": [
                {
                        "i": "time-before 2018-04-28T16:02:23.47112259Z"
                },
                {
                        "i": "ipaddr 123.123.123.123"
                }
        ],
        "l": "lnd",
        "i64": "AwoQ7V1quyefYWYwh9TyFCJCBhIBMBoWCgdhZGRyZXNzEgRy....",
        "s64": "BqjN2qrARiy4dRfX7H__3t0XRWqXtVjNs5gyXL7oU9Q"
}

lncli delegatemacaroon --format=hex --timeout=3600 --ip_address=123.123.123.123:

{
        "macaroonHex": "0201036c6e6402bb01030a10ed5d6abb279f61663..."
}

Once new first-party caveats are introduced, they can be implemented here as well.

@aakselrod:
Does this cover your idea as described in #283?
As I see it, there are at least two ways to delegate macaroons in lnd:

1. Take one of the three existing macaroon files (admin.macaroon, invoice.macaroon and readonly.macaroon) and add first-party caveats to them (as implemented in this PR).
2. Bake fresh macaroons by using the encrypted root key in macaroons.db and define custom operations/permissions. Then add first-party caveats to those newly baked macaroons.
   The second option has the advantage that the user can customize the allowed operations/permissions. But the big disadvantage that the macaroons.db need to be unlocked (lnd needs to be stopped) and decrypted with the wallet password.

Am I correct in the assumption that you meant to implement option 1 in your issue, instead of option 2?

Thanks for your feedback!

[vegardengen]

There is definitely a need for option two. For example in the woocommerce LND plugin, there is the need for invoice macaroon rights plus some other read-rights. For now, that means we need to give it the admin macaroon, which is not too good security wise.

[guggero]

I see, thanks for your input!

In that case I propose to add a new gRPC method named NewMacaroon:

• Introduce a new permission entity named macaroon (could be used for macaroon based RPCs mentioned in Add support for accounting-based macaroons #291 too).
• write access to the entity macaroon is necessary to call the method NewMacaroon.
• The admin.macaroon gets write access to macaroon.
• Add a new command to lncli called newmacaroon that calls this gRPC method. This removes the need to read the macaroons.db in the command line client and therefore removes the disadvantages mentioned in option 2 above.
• As parameters to the NewMacaroon method we could pass the list of entity/action pairs for the allowed operations, as well as first-party caveats.

What do you think?
If there are no objections, should I create a new PR or continue here?

[aakselrod]

Tested the new changes (rebased on current master). This LGTM.

[aakselrod]

Tested ACK. LGTM, again. Rebases on current master with no issues AFAICT.

[guggero]

Now that #1160 is merged, this doesn't offer any new functionality. Closing as redundant.