Currently, the client with provided -rpcauth option still creates the .cookie file.
However, if -rpcuser and -rpcpassword are provided the .cookie file is not generated.
This PR makes client behavior consistent.
Refs:
Also this PR ensures that the auth cookie is still generated in regtest mode on test purposes.
Ensure that the auth cookie is still generated in regtest if rpcpassword
is not provided.
Concept ACK, will test.
ensures that the auth cookie is still generated in regtest mode on test purposes
Is this necessary for the test framework?
Is this necessary for the test framework?
Yes, it is. See: https://github.com/bitcoin/bitcoin/blob/de5af41e3567dd9660b3e9734113dccbce394207/test/functional/test_framework/util.py#L314
Unless I'm reading this wrong, this provides no way to keep bitcoin-cli just working if you'd added an rpcauth line to enable use by an application.
Unless I'm reading this wrong, this provides no way to keep bitcoin-cli just working if you'd added an rpcauth line to enable use by an application.
If the client is running with the -rpcauth option the bitcoin-cli needs authorization (with this PR).
The same behavior is for the client with -rpcuser and -rpcpassword options set (on master).
Is there any downside to having two mechanisms to auth with?
Is there any downside to having two mechanisms to auth with?
There are three mechanisms to authenticate with:
.cookie file-rpcuser and -rpcpassword options to the RPC server (bitcoind or bitcoin-qt; should be deprecated as a plain text RPC password is exposed)-rpcauth option to the RPC server (bitcoind or bitcoin-qt)Before #7044 was merged providing -rpcuser and -rpcpassword options to the RPC server effectively disabled the .cookie authorization for local instances of the bitcoin-cli client. IMO, this behavior follows the Principle of Least Astonishment.
After #7044 is merged the behavior of the RPC server with -rpcauth option differs from the behavior with -rpcuser and -rpcpassword options. This PR fixes this issue according with the Principle of Least Astonishment.
Is there any danger to always create the cookie?
Is there any danger to always create the cookie?
I'm not a security expert.
"to always create the cookie" seems equivalent to giving access to the RPC interface to any non-privileged user (e.g., if /etc/bitcoin/bitcoin.conf exists). Is it acceptable for nodes running for business?
If they have access to the conf file, they might as well put the rpcauth pair in there and don't need the cookie.
... they might as well put the rpcauth pair in there ...
This requires write access.
However, only read access is needed to read the cookie from /etc dir or its subdir.
The cookie is not available to arbitrary non-privileged users. If it is, your configuration is already screwed up. The cookie is protected by the same mechanism as the filesystems that protect the wallet. Also, being able to read the conf files means that you can read the credentials which we should treat as equivalent to handling them (yes, they're hashed, but that is just belt-and-suspenders).
If the client is running with the -rpcauth option the bitcoin-cli needs authorization (with this PR).
Yes, and I think that is a bad change. That means adding an rpcauth to enable an application like joinmarket or an explorer to use the daemon will then make the bitcoin-cli unusable.
rpcuser/rpcpassword are deprecated and should eventually go away; thus eliminating any potential for behavioural confusion.
I see nothing wrong with having an option to turn off the cookie (-norpccookiefile would be logical), it just shouldn't be overloaded with rpcauth.
NAK
However, if -rpcuser and -rpcpassword are provided the .cookie file is not generated.
Then maybe change this? Especially considering these parameters are deprecated.
NAK.
By luck I found out this pull request just when this behavior allowed me to fix a bug. If this PR was merged, it would break my use case.
In a BTCPay Server deployment, we have a bunch of applications connecting to Bitcoin Core RPC.
For most application, we use cookiefile because it is simpler to configure. The less parameters there is, the less chance to screw up.
However, some application (like LND) does not handle cookie authentification right. Cookie authentication requires the client to read the file before calling the API. Instead LND is caching the cookie when it starts. Meaning that if bitcoin core restart (because OOM for example) then LND is in a zombie state. Not crashing, not restarting, just hanging, looping indefinitely trying to connect to RPC with outdated creds. After report, it does not seems the priority of LND team to fix this critical bug.
The only fix I got was to use rpcauth with a fixed password just for LND.
But I want to keep cookiefile for the other applications because they always worked fine with it and I don't want to break things that work. (Also cookiefile auth is more secure)
https://github.com/btcpayserver/btcpayserver-docker/commit/effa2a3884c660fd13b95bad4a7f3b57292af9d8
There is no reason that rpcauth, rpcuser/rpcpassword and cookiefile to be mutually exclusive.
Also notice that the behavior being inconsistent forced me to use rpcauth instead of the deprecrated rpcuser/password. Which is a good thing.
Thanks for everyone's input. Closing this for now, since it seems too controversial.
Also cookiefile auth is more secure @NicolasDorier How so?
AFAIK cookie file is just a simple solution for authentication "inside" the host - both the server and the client have access to it. Of course the cookie can be shared to other hosts (you can read containers here) but I don't think that's the point.
@promag say there is 10 000 deployment in the wild of btcpay, and we are using a fixed password. So those 10 000 deployment have same RPC pass. Now if by mistake the RPC ever get exposed, we have 10 000 deployment exposed. At least with cookieauth the deployments don't have the same creds.