New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) #10615

Open
wants to merge 12 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@luke-jr
Member

luke-jr commented Jun 16, 2017

Simple rebase of current RPC stuff. No endpoints yet.

Show outdated Hide outdated src/httprpc.cpp

@luke-jr luke-jr changed the title from RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet to RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) Jun 18, 2017

@ryanofsky

ACK b77b2f2.

Needs updated documentation, also would be good to have python tests.

Tested with:

bitcoind -regtest -wallet=w1.dat -wallet=w2.dat -debug=1
bitcoin-cli -regtest -rpcuser=user1 -rpcpassword=V6CGvawtTWCHzt51knRvFfTejjjfy06UzSt_FiB3Fxw= getwalletinfo
bitcoin-cli -regtest -rpcuser=user2 -rpcpassword=V6CGvawtTWCHzt51knRvFfTejjjfy06UzSt_FiB3Fxw= getwalletinfo
bitcoin-cli -regtest -rpcuser=user3 -rpcpassword=V6CGvawtTWCHzt51knRvFfTejjjfy06UzSt_FiB3Fxw= getwalletinfo

And $HOME/.bitcoin/bitcoin.conf:

rpcauth=user1:51902a7be9c9911079af388a927f$22904ad1bfec659ee1e61d1b3dd73f7b552c6d2d0d1e9f71f6ee833954d062da:w1.dat
rpcauth=user2:51902a7be9c9911079af388a927f$22904ad1bfec659ee1e61d1b3dd73f7b552c6d2d0d1e9f71f6ee833954d062da:w2.dat
rpcauth=user3:51902a7be9c9911079af388a927f$22904ad1bfec659ee1e61d1b3dd73f7b552c6d2d0d1e9f71f6ee833954d062da:-
Show outdated Hide outdated src/rpc/server.h
Show outdated Hide outdated src/rpc/server.h
Show outdated Hide outdated src/httprpc.cpp
@ryanofsky

There was a lot of objection at last IRC meeting (https://botbot.me/freenode/bitcoin-core-dev/msg/87311878/) to choosing wallet based on RPC username & password, mostly for security reasons ("securing RPC for multiple users is absolutely a nightmare").

Personally, I don't like the choosing wallet based on username because I think it makes for a clumsy UI. Adding support for a simple -wallet= option to bitcoin-cli and working with regular cookie authentication just seems a lot more user-friendly than having to deal with -rpcauth, the share/rpcuser script, and all of that.

ACKing this PR though because it makes multiwallet usable, and the implementation is pretty clean. If we don't want to use rpcauth for wallet security, we could allow all users to access all wallets and just interpret the new rpcauth wallet option as the default wallet for the user.

Show outdated Hide outdated src/httprpc.cpp
@jnewbery

This comment has been minimized.

Show comment
Hide comment
@jnewbery

jnewbery Jun 28, 2017

Member

Multi-user for multiwallet is definitely a very useful feature and one that we should be aiming for long-term, so this is good to see. I think the implementation some more work before its ready:

  • most importantly, having individual user wallet access authentication will give users the impression that it's safe to open RPC access to multiple users, which it absolutely isn't. Just using the standard RPC commands, a malicious user could cause mischief by stopping the node, changing consensus state using invalidateblock/preciousblock, eclipse the node using disconnectnode/addnode, etc. RPC is not a secure interface and we should be very careful to not give users the impression that it is.
  • this implementation adds a lot of #ifdef ENABLE_WALLETs to libbitcoin_server.a. We should be trying to remove those in order to remove circular dependency between libbitcoin_server.a and libbitcoin_wallet.a (see #7965). This PR would make future work to cleanly separate wallet from server more difficult.
  • this implementation needlessly binds multiwallet to multi-user. It does not allow a single user to have access to multiple wallets or select a wallet on a per-call basis.

So, definite concept ACK that we should do this, but I think it should be sequenced after wallet separation. That would make the implementation a lot cleaner and make it easier to provide an implementation that is secure and safe for users.

Member

jnewbery commented Jun 28, 2017

Multi-user for multiwallet is definitely a very useful feature and one that we should be aiming for long-term, so this is good to see. I think the implementation some more work before its ready:

  • most importantly, having individual user wallet access authentication will give users the impression that it's safe to open RPC access to multiple users, which it absolutely isn't. Just using the standard RPC commands, a malicious user could cause mischief by stopping the node, changing consensus state using invalidateblock/preciousblock, eclipse the node using disconnectnode/addnode, etc. RPC is not a secure interface and we should be very careful to not give users the impression that it is.
  • this implementation adds a lot of #ifdef ENABLE_WALLETs to libbitcoin_server.a. We should be trying to remove those in order to remove circular dependency between libbitcoin_server.a and libbitcoin_wallet.a (see #7965). This PR would make future work to cleanly separate wallet from server more difficult.
  • this implementation needlessly binds multiwallet to multi-user. It does not allow a single user to have access to multiple wallets or select a wallet on a per-call basis.

So, definite concept ACK that we should do this, but I think it should be sequenced after wallet separation. That would make the implementation a lot cleaner and make it easier to provide an implementation that is secure and safe for users.

Show outdated Hide outdated src/httprpc.cpp
Show outdated Hide outdated src/httprpc.cpp
Show outdated Hide outdated src/httprpc.cpp
Show outdated Hide outdated src/httprpc.cpp

@ryanofsky ryanofsky referenced this pull request Jan 23, 2018

Open

RPC Whitelist Files #12248

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment