-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for append-only option #2
Comments
Indeed, I need to find out how to add this to the caddy plugin. |
I've been doing some research to see if I could determine how to do this. Looking through @mholt's docs, I think the answer on how to add support for the rest-server's append-only flag may be in https://github.com/mholt/caddy/wiki/Writing-a-Plugin:-Directives. I wish I could be of more help, I'm just not familiar enough with Golang or Caddy plugins at this point to contribute more. |
Yes, that's on the right track. There'll probably be some keyword added for the Caddyfile so that restic would be invoked with append-only. :) |
Thanks for chiming in. That makes sense. Can you point me to any existing simple plugin examples I could reference to see how it was implemented in other code? I'm a novice programmer so having examples to follow help 😄 |
Sure, pick any here: https://github.com/mholt/caddy/tree/master/caddyhttp - these are all the standard HTTP plugins. A pretty simple one is Or mime, a little more advanced: https://github.com/mholt/caddy/blob/master/caddyhttp/mime/setup.go |
Thanks again. Now to find time to dive in and learn. |
FYI, Nick (@ncw) recently added an option to provide a restic REST server implementation in Among others, he's written a new HTTP handler which serves the restic REST protocol, independent of the one from the It may be valuable to integrate the code (if the license permits it) into caddy, Nick's implementation is much more configurable and portable as far as I can see. Bonus point: The append only mode can also be integrated into rclone afterwards ;) |
Good to know The code appears to be under MIT so licensing should not be
an issue if someone wanted to pursue this.
https://github.com/ncw/rclone/blob/master/COPYING
…On Mar 13, 2018 3:32 AM, "Alexander Neumann" ***@***.***> wrote:
FYI, Nick ***@***.*** <https://github.com/ncw>) recently added an option to
provide a restic REST server implementation in rclone (a cool cloud sync
tool which supports many different services) here: rclone/rclone#2116
<rclone/rclone#2116>
Among others, he's written a new HTTP handler which servers the restic
REST protocol, independent of the one from the rest-server, starting
here: https://github.com/ncw/rclone/pull/2116/files#diff-
2bd148b7531377d2d2cfe6cd70c0c74fR192
It may be valuable to integrate the code (if the license permits it) into
caddy, Nick's implementation is much more configurable and portable as far
as I can see.
Bonus point: The append only mode can also be integrated into rclone
afterwards ;)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACjDujT4_wWAllSG2I-nrUA3EGKO90KWks5td4QwgaJpZM4QKEI4>
.
|
@fd0 That's great! Do you know if those changes allow us to proxy a backup? i.e. if the backup is happening on an untrusted computer, and we need to keep the cloud storage credentials locally on the proxy server which we trust? |
Yes, that's one of the use cases. You could, for example, run
The rclone/ssh process is automatically started and stopped by restic, and communication happens over HTTP2 over stdin/stdout, so there's no network socket involved. This will be supported when restic/restic#1657 is merged, but you can check it out already and test it with the master version of I'd love to get some feedback btw. Either way, the You could even hard-code the All of that isn't documented yet (but still very exciting!) |
@fd0 I finally had a chance to sit down and try this today, and it works so far! Thank you so much to both you and @ncw for making this possible. This is extremely awesome. Looking forward to when both programs have it in their stable release! So, I dunno, in my mind, since credentials don't have to be given to the machine doing the backup, does that eliminate the need for the original feature request (--append-only in the caddy plugin)? If so, we can close this. |
That's great you had a chance to try this and confirm it works. I haven't had a chance to look
into adding append only support.
Regarding your question, I'm not sure. Here's the description from the
current rest server:
The --append-only mode allows creation of new backups but prevents deletion
and modification of existing backups. This can be useful when backing up
systems that have a potential of being hacked.
I think the proxy model would help when dealing with untrusted computers.
Supporting this flag would give an another way to mitigate the threat for
people who prefer not to go through a proxy. People who care about all this
may prefer the added benefit the proxy method offers making this point less
of a concern.
I'm putting this out here to hear other thoughts. I'm good closing this
issue if others agree this mitigates the need of the original feature
request.
|
My personal view is that EDIT: Okay, I could see the value in --append-only still if the backup owner didn't want an adversary, if they took over their computer, to be able to delete their remote backups. In the proxy situation, the adversary would not have credentials to the cloud storage, but even with proxying without --append-only, they could still run delete commands that get proxied, I suppose. |
@mholt I tend to agree. For the super paranoid, the backend storage could also be configured to to retain deleted objects for a period of time: |
No, that's not the case, it's a slightly different case. Suppose you have a machine (e.g. a server) which does backups of important data with restic to B2, and attackers gained access to this server. Up to now, the attackers can just extract the credentials for B2 and delete all data in the bucket. After all, restic needs these credentials for its operation,so they must be present on the server. When you use rclone as a proxy, this is not the case any more: The attackers would just find access credentials for the rclone (e.g. an SSH key, or username and password for the REST backend). So they can't directly access the data stored at B2. But they are still able to delete all data in the repository, because that's what restic needs to be able to do to run This is where the append-only mode comes into play: The idea here is that you backup to rclone or the REST server, and it restricts the client to only add data (except lock files). It isn't possible to run Using rclone as a proxy hides the B2 credentials, the append-only mode disallows attackers to delete data. It also helps against accidental data loss. ;) Does this description make the use case clearer to you? |
Yep! Thanks, that makes sense. |
Nice to learn about I'll migrate from this plugin to rclone; feel free to close this issue if you think it's not relevant anymore since we have a better integration with rclone. |
Ah, thanks a lot for the pointer to the PR for rclone. It helped me find a bug in rclone as well as in the REST server :) |
I didn't find a way to use the option
--append-only
from the lastrest-server
in this plugin.Having feature parity between server and plugin would be great.
The text was updated successfully, but these errors were encountered: