I’m looking at restic as a replacement for obnam and I have some questions about client authentication.
With obnam, if you’re using encryption you can assign access rights for different clients to each key which has been added to the repository. This lets you set up the repository with a master key with access to everything and also client specific keys which can only access the backups for that client.
Is it possible to do this with restic? From what I’ve seen so far adding keys just lets you use additional passwords for access and any valid password has full access to the repository.
Indeed, that’s not possible with restic and each password/key will have full access to the repo. We have plans to eventually add multiple different keys with different access rights (in terms of “which data can be decrypted”), but for now the repo internally only uses a single pair of keys for encryption and authentication.
Do you have a pointer on documentation how this is implemented in obnam?
We have two issues tracking functionality similar to what you describe, please subscribe over there to get notified of any (eventual) progress:
IMHO backups isolation through multiple passwords would be a game changing feature for restic. I report here a proposal that I made time ago for Duplicati, rephrasing everything for restic.
For this proposal to work, each user should have a personal backup password. For every data block, two independent checksums are computed (using two different algorithms). One (called data-checksum) is used to identify the data block (as restic currently does) and registered in the file name of the stored data block. The other one (called encryption-checksum) is stored in an archive (for instance SQLite database) encrypted using the personal backup password. The data block is first compressed, then encrypted using the encryption-password.
When another user runs his backup in the same repository, for every data block the same two checksums are computed. If the data-checksum does not match any one already stored, the same steps above are performed. If instead the data-checksum matches one already stored, only the encryption-checksum is stored (not the data block). This allows the user to unencrypt the data block in future for a restore.
That’s an interesting idea, I think I understood what you described and how the system works. Even better, I think this may even work.
We’ll keep it mind for later, this would require massive changes in the restic architecture and repository format. That may only be possible in the long term.
Cool!! For an additional layer of safety (but maybe not needed) a repository password shared among all users could be defined to further encrypt all data.
While zstd is very nice, it’s written in C. I think it’s very important for the restic project as a whole to not depend on any C code, which would complicate the build process a lot. So, let’s see what’s available once we get around to implementing compression.
It should be fairly easy to obtain a statically linked standalone executable from a go program calling C libraries using gccgo. Please find a working example here.
Notes:
With SWIG 3.0 the command swig -go -gccgo example.i should actually be swig -go --intgosize 64 -gccgo example.i, see: http://www.swig.org/Doc3.0/Go.html
To obtained a statically linked standalone executable (as with gc) the command gccgo main.o example.o example_wrap.o example_impl.o -o hello should actually be gccgo main.o example.o example_wrap.o example_impl.o -static -o hello, see: https://golang.org/doc/install/gccgo#Using_gccgo
Compilation of the zstd object file would be needed only on a version update.