Topic: ACL for RPC? Any interest? (Read 1204 times)
It would be nice if bitcoind could use PAM for password checking, at least on systems where PAM exists.
Oh gosh I was not thinking of exposing to the internet! Gosh no!
I was thinking of usernames who run stuff that needs some info the daemon can provide. I do not like the idea of having such a username know the password that can do actual wallet stuff, transactions, etc.
For example, a CGI script to provide some info or other that somehow relies on some info the daemon can provide.
I would not want the user that CGI runs as to have any access other than exactly what it needs to do its job.
-MarkM-
I was thinking of usernames who run stuff that needs some info the daemon can provide. I do not like the idea of having such a username know the password that can do actual wallet stuff, transactions, etc.
For example, a CGI script to provide some info or other that somehow relies on some info the daemon can provide.
I would not want the user that CGI runs as to have any access other than exactly what it needs to do its job.
-MarkM-
In general, it is simply not advised to expose the RPC server to the Internet. There are a great many things that should be done before it would be considered safe for exposing to the Internet.
A proxy server is a much better suggestion. Then you may expose precisely, and only, what you need. That's how pool servers work. Proxy servers also permit accessing multiple backend bitcoind's and other flexible solutions.
A proxy server is a much better suggestion. Then you may expose precisely, and only, what you need. That's how pool servers work. Proxy servers also permit accessing multiple backend bitcoind's and other flexible solutions.
Yeah its actually the reverse of how I expressed it, looking at new calls made me think it'd be nice to be able to disable old calls for some users.
Basically I thought wow some nice harmless info-providing calls now, but what use are they really if giving access to them means also giving access to the wallet, the ability to send coins, and so on... all the original old things you don't have any good reason, probably, for letting anyone else have access to.
-MarkM-
EDIT: Of course being able to have multiple daemons use the same blockchain would also work, you could have a wallet-less daemon for the info calls, without needing a whole new copy of the blockchain for it. But that doesn't seem to be on the way any time soon so ACL seems a good alternative.
Basically I thought wow some nice harmless info-providing calls now, but what use are they really if giving access to them means also giving access to the wallet, the ability to send coins, and so on... all the original old things you don't have any good reason, probably, for letting anyone else have access to.
-MarkM-
EDIT: Of course being able to have multiple daemons use the same blockchain would also work, you could have a wallet-less daemon for the info calls, without needing a whole new copy of the blockchain for it. But that doesn't seem to be on the way any time soon so ACL seems a good alternative.
many cases it's used as a server.
0_oI certainly hope people are not exposing the bitcoin rpc port to the open internet.
You'd be surprised. Even if it's not exposed though, if an attacker could gain access to your network they could run RPC all day and you'd never know.
many cases it's used as a server.
0_oI certainly hope people are not exposing the bitcoin rpc port to the open internet.
Yes its a good idea for sure. As soon as I saw the latest list of commands my first thought was gosh wouldn't it be nice to disable some of those for some callers.
I would have ended up having my shell scripts check args before passing them to the daemon but if the shell script knows the password a caller would have had to be able to execute it without being able to read it, which strikes me as an unlikely combination of permissions, or the password would have to be hidden in a config file but, again, setting up a user to be able to execute the script as a user who can access the config file, but not be able to read the config file itself sounds kind of tricksy, just the kind of thing that is going to be one of those nasty little nitpacky things that bites you next time you set everything up from scratch on a shiny new blank machine...
So yeah, great minds think alike. (That fools seldom differ is irrelevant, of course...
)
-MarkM-
I would have ended up having my shell scripts check args before passing them to the daemon but if the shell script knows the password a caller would have had to be able to execute it without being able to read it, which strikes me as an unlikely combination of permissions, or the password would have to be hidden in a config file but, again, setting up a user to be able to execute the script as a user who can access the config file, but not be able to read the config file itself sounds kind of tricksy, just the kind of thing that is going to be one of those nasty little nitpacky things that bites you next time you set everything up from scratch on a shiny new blank machine...
So yeah, great minds think alike. (That fools seldom differ is irrelevant, of course...
)-MarkM-
If you do it, I'd suggest implementing it as a proxy that sits in front of bitcoind.
But before you do that, you should do some googling to see if somebody has already written a JSON-RPC-over-HTTP proxy that implements per-method access control.
But before you do that, you should do some googling to see if somebody has already written a JSON-RPC-over-HTTP proxy that implements per-method access control.
I understand what you mean but the point was more or less to make bitcoind itself more secure since in many cases it's used as a server.
In my use case I'm using ONLY the raw transactions API, there really is no wallet to speak of, so it's no strictly necessary. However I can see a use case where someone uses it to back an eWallet type service (probably is already being used this way), in this case it would be nice to restrict access to certain features so that only particular users or services could do certain functions.
Anyways just a thought.
If you do it, I'd suggest implementing it as a proxy that sits in front of bitcoind.
But before you do that, you should do some googling to see if somebody has already written a JSON-RPC-over-HTTP proxy that implements per-method access control.
But before you do that, you should do some googling to see if somebody has already written a JSON-RPC-over-HTTP proxy that implements per-method access control.
Yes, this would be useful for me.
I've been taking a long close look at bitcoind especially now that the raw transactions API is in.
I'm considering implementing an access control list against the RPC functionality and was wondering if anyone else would be interested in a patch to support access control.
The purpose behind this would be to provide granular permissions based access to bitcoind rpc calls. This would allow for instance an untrusted app to view your wallet but not be able to send or dump the keys etc.
Anyways I'm mostly posting this to gather interest, if there is sufficient interest I will go ahead and do it and release a patch when it's done. So let me know what you think.
I'm considering implementing an access control list against the RPC functionality and was wondering if anyone else would be interested in a patch to support access control.
The purpose behind this would be to provide granular permissions based access to bitcoind rpc calls. This would allow for instance an untrusted app to view your wallet but not be able to send or dump the keys etc.
Anyways I'm mostly posting this to gather interest, if there is sufficient interest I will go ahead and do it and release a patch when it's done. So let me know what you think.
Jump to: