Should a JSON-RPC user be required to use a password when backing up the wallet? I was surprised I was able to back up my wallet over JSON RPC without requiring the wallet password (or even without a secondary backup-only password)

I'm concerned that this could create a DOS attack if the following were to occur


A read-only wallet service is created to perform low-risk operations with the wallet
That low risk service is somehow exploited via a web front end, etc.
The background process (now in control of the attacker) issues the backupwallet command


I think that can be a risk depending on a number of scenarios:


The user can save the file with many different random names and fill up the drive (DOS attack)
The user can overwrite system files with a copy of the wallet (DOS again)
If previous files aren't overridden, and an error is returned, (due to duplicate file, locked file, etc) the attacker can infer information about the remote file system
If the system supports pipes, perhaps the wallet can be piped to another remote system (/dev/???)


So I'm wondering if a separate, backup-only password should be created to address this issue.  Namely I don't want to use the "decrypt wallet" password.  


Also I'd like to force that all backups go to a specific directory (and not any other drive/path)
Is this a good idea and if so, how should it be incorporated into the network?
The JSON-RPC was never intended to be open to the public, hence the required rpcuser and rpcpassword. For added security it should also be configured to either listen only to the loopback interface or the allowed IPs limited to a few trusted sources.

The wallet password is used to access the encrypted private keys, that's the reason everything involving either adding new private keys or signing with the private keys requires the wallet to be unlocked.

backupwallet exports the keys in their encrypted form and therefore does not require the passphrase.

If you have to allow JSON-RPC access to untrusted users, put a filter in front of it.