Allow groups of accounts to access the RPC cookie file #25270

issue alevchuk openend this issue on June 2, 2022
  1. alevchuk commented at 11:44 pm on June 2, 2022: none

    Context I have multiple accounts on the same box that need to run clients of bitcoind. In particular it’s LND and electrs. Bitcoind itself runs in a separate account. I have other accounts that I don’t want to have access to bitcoin: e.g. Grafana (graphs/charts web UI). So, the cookie file can be shared amount the relevant accounts via a group. On the file system a group read permissions can be set on each file. I call the group “bitcoinclients”. I setup a directory where new files will inherit the bitcoinclients group and will be created with the u=rw,g=r,o= permission. This means bticoin account can write the file, bitcoinclinets group can read it, and no one else has access.

    Is your feature request related to a problem? Please describe. The problem is that when bitcoind is restarted it drops the group read permission on the cookie file so clients in other unix accounts can’t read the file.

    Describe the solution you’d like There should be a config that allows controlling permissions of the cookie file. Just a boolean that sets the read permissions on the group would be sufficient.

    Describe alternatives you’ve considered I setup a chronos workaround but I bet more people will have to re-invent this wheel as the cookie file gets wider adoption.

    Additional context Cookie file has more security over user+password auth. User+password auth is being deprecated in favor of the cookie file.

  2. alevchuk added the label Feature on Jun 2, 2022
  3. ghost commented at 2:12 am on June 3, 2022: none
    Have you tried RPC whitelists? https://github.com/bitcoin/bitcoin/pull/12763
  4. alevchuk commented at 5:07 am on June 3, 2022: none

    Have you tried RPC whitelists? #12763

    Whitelists use rpcauth which sends the password in clear text to the server https://github.com/bitcoin/bitcoin/blob/0de36941eca1bff91420dd878eb097db2b1a596c/src/httprpc.cpp#L130

    This unlike the cookie file is not resilient to server spoofing attack. Basically if my grafana Linux user gets compromised then it can get the password for every bitcoin RPC user.

    In my case both RPC users have a wide variety of methods that need to be available, so locking down with rpc whitelists would not help much. I would not choose that over keeping random users out.

  5. ryanofsky commented at 5:12 pm on June 3, 2022: contributor

    Agree it would be useful to set permissions on the cookie file, and this would be a simple feature to implement. But I don’t think it would be right to say rpcauth is less secure than cookie auth.

    The main advantage cookies have over RPC passwords is just their convenience. Other than being generated randomly each restart, they don’t provide extra security. You could write a script to randomly generate new passwords for grafana each time bitcoin is restarted to get the same effect as using a cookie.

    RPC passwords also have an advantage over cookies because they are hashed. So if an attacker manages to get read access to the bitcoin directory, they can’t easily use password hashes to connect to the server, while they could straightforwardly use the cookie file to connect.

    Also it looks like depending on your setup you may be able control permissions of the cookie file in current versions of bitcoind by running umask 0027 and passing -sysperms argument.

  6. darosior commented at 12:25 pm on June 6, 2022: member
    I agree this would be nice to have. I personally use ACLs to achieve the same.
  7. bitcoin deleted a comment on Jun 7, 2022
  8. kristapsk commented at 3:10 pm on June 8, 2022: contributor
    In RaspiBolt we use -startupnotify="chmod g+r /home/bitcoin/.bitcoin/.cookie", to add group permission after RPC cookie file is created. https://github.com/raspibolt/raspibolt/pull/846
  9. alevchuk commented at 3:30 pm on June 8, 2022: none

    In RaspiBolt we use -startupnotify="chmod g+r /home/bitcoin/.bitcoin/.cookie", to add group permission after RPC cookie file is created. raspibolt/raspibolt#846

    Thanks!

    This is evidence that everyone is going to implement this in many different ways. All of which will be more complex and less audited than bitcoin choosing the right permissions when creating the file.

    I bet more people will have to re-invent this wheel as the cookie file gets wider adoption.

  10. alevchuk closed this on Jun 8, 2022

  11. alevchuk reopened this on Jun 8, 2022

  12. lsunsi commented at 12:13 pm on July 25, 2022: none
    I’ll be using the @kristapsk solution as well, but I’d love for a ‘cookie_umask’ option or something to be added.
  13. willcl-ark commented at 5:05 pm on March 15, 2023: contributor

    Am I wrong in thinking that there is probably still demand for this, even though #26088 was closed (because #17127 was merged, which does not address this issue), and we have an number of currently-working alternatives:

    1. The raspiblitz startupnotify script: -startupnotify="chmod g+r /home/bitcoin/.bitcoin/.cookie"
    2. With user+password by using stunnel to situate the RPC port behind ssl: stunnel -d 8332 -r 127.0.0.1:8332 -p /path/to/your/certificate.pem -k /path/to/your/key.pem -o /var/log/stunnel.log (cleaner with a config file + service).
    3. Cronjobs or similar…

    It seems to me that we should either make the cookie group-readable by default, or provide an option to enable that (preferred).

  14. maflcko added the label RPC/REST/ZMQ on Mar 16, 2023
  15. pinheadmz commented at 2:40 pm on April 27, 2023: member
    This issue is unlikely to be fixed in Bitcoin Core. We’ll close for now, but feel free to open another issue or pull request with a fix.
  16. pinheadmz closed this on Apr 27, 2023

  17. AndySchroder commented at 1:52 am on February 24, 2024: none

    Am I wrong in thinking that there is probably still demand for this, even though #26088 was closed (because #17127 was merged, which does not address this issue), and we have an number of currently-working alternatives:

    1. The raspiblitz startupnotify script: `-startupnotify="chmod g+r /home/bitcoin/.bitcoin/.cookie"`
    
    2. With user+password by using `stunnel` to situate the RPC port behind ssl: `stunnel -d 8332 -r 127.0.0.1:8332 -p /path/to/your/certificate.pem -k /path/to/your/key.pem -o /var/log/stunnel.log` (cleaner with a config file + service).
    
    3. Cronjobs or similar...
    

    It seems to me that we should either make the cookie group-readable by default, or provide an option to enable that (preferred).

    Note:

    -startupnotify="chmod g+r /home/bitcoin/.bitcoin/.cookie" works on the command line, but startupnotify="chmod g+r /home/bitcoin/.bitcoin/.cookie" inside bitcoin.conf does not.

    I am not sure why the two ways behave differently, but debug.log says it is executing it with either approach, even though passing it on the command line is the only one that actually seems to change the permissions of the .cookie file.

  18. willcl-ark commented at 7:57 pm on February 29, 2024: contributor

    Note:

    -startupnotify="chmod g+r /home/bitcoin/.bitcoin/.cookie" works on the command line, but startupnotify="chmod g+r /home/bitcoin/.bitcoin/.cookie" inside bitcoin.conf does not.

    I am not sure why the two ways behave differently, but debug.log says it is executing it with either approach, even though passing it on the command line is the only one that actually seems to change the permissions of the .cookie file. @AndySchroder

    I think the issue is coming from your use of " " surrounding the command inside bitcoin.conf. Try like this (which works for me):

    bitcoin.conf:

    0startupnotify=chmod g+r /home/bitcoin/.bitcoin/.cookie
    

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-24 00:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me