So I was just thinking, what if we had permission levels for the password/ keys. For example, read write delete check full.
Read allows the key to copy/ restore data
Write allows backup to take place
Delete allows forget prune
Check allows you to do restic check, for example a hosted environment where you don’t want to allow access to your data but has direct/ better access to the repositories , like a hosted minio/ garage or even a VPS checking your B2 hosted repo.
Full basically full access as is.
Permissions can be given with combination, e.g read write and check
Initially when you initialize a repository, that password / key would always have full access.
@satish, check out npbackup which has something like this (and more):
Permission system to limit client operations:
- Backup only permission
- Backup, list and restore permissions
- Restore only permissions
- Full permissions including destructive operations
Nice link, but I was thinking to have the ACL within restic itself since that allows you to roll out from any client to any other service without an additional layer, it then offers a whole range of additional possibilities. Imagine a backup key not being able to delete even accidentally, or a check key not even accessing the data. For example on a hosted minio/ garage server, it can check the data but still doesn’t know what it is. Or a VPS checking a S3 based repository without needing to use the bandwidth of the actual office/ premise.
Such a deletion protection can’t be implemented in restic itself (at least nothing that can’t be trivially bypassed). It has to be enforced by the backend. The other ACL types would either similarly require a server side that enforces them or use some fancy encryption scheme. To be honest, I don’t even know whether the latter is even possible or what the caveats would be.