Skip to content
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

Append mode and untrusted client users #4722

Closed
u1735067 opened this issue Aug 10, 2019 · 2 comments
Closed

Append mode and untrusted client users #4722

u1735067 opened this issue Aug 10, 2019 · 2 comments

Comments

@u1735067
Copy link

Hello,

I'm using Borg 1.1.10 a bit differently than most case (I think ?) :

  • Repo is stored on a remote untrusted location, mounted directly on the server
  • A scheduled task on the server, with access to the mountpoint, creates the backups and prune the old ones
  • Users on the server can't access the mountpoint but I want them to be able to read or create archives without deleting them, so I'm using the client-server mode locally : a socket is available to the users, connected to an append-only borg serve instance

At first I though this would do what I want, allowing them to read or create archives, but digging the documentation I understand deleting an archive is from server's point of view adding a transaction, thus not prevented.

It seems to be similar to what's discussed in #2251, but I may have not understood everything and have a different use-case, so I have to ask.

The repo transaction list is managed by the server (or a non-remote instance), but transactions themselves are unreadable to the server as I understand, so could this be done : when transactions are received by the server in append-only mode, they're marked as such in the transaction log, and when a destructive/compaction operation is ran in non-remote instance, transaction log is checked first and if a transaction result in data destruction while marked as append-only, it is disregarded/deleted ?

On another topic, users could also change the passphrase, but the key can be exported and reimported to cancel their change :)

Alexandre

@ThomasWaldmann
Copy link
Member

If a borg client has access to a borg repo (directly via fs or via a borg server), the client can do any logical operations it wants (get, put, delete).

If the repo runs in append-only mode, new operations are always appended at the end, preserving past repo states. The transaction log file serves as information so you can see where transactions started/ended - see the docs about append-only mode for details (it does what is documented there, no more, no less).

The repo transaction list is managed by the server (or a non-remote instance),
but transactions themselves are unreadable to the server as I understand,

The transaction log is in clear text, but it is just for information and always appended to.

so could this be done : when transactions are received by the server in append-only mode,
they're marked as such in the transaction log, and when a destructive/compaction operation
is ran in non-remote instance, transaction log is checked first and if a transaction result in data
destruction while marked as append-only, it is disregarded/deleted ?

There is no concept of non-remote having more permissions than remote.
There is just access or no access.

Usually (local client, far away untrusted remote backup server) it is rather like that backup server does not have the crypto keys, so it is only seeing low-level operations done by the client and can't see cleartext metadata nor data.

The server can't know whether delete operations are good or bad. If you never want to delete anything, just ever stay in append-only mode.

I somehow have the impression that this was already discussed in an older ticket, so unless there is some new / different idea, please continue there.

@u1735067
Copy link
Author

My approach was probably not the good one / possible at all, however in my case as the "control-server" (like the "trusted admin client" in #2251) is also aware of the keys (but not the "file-server" which host the files), maybe being able to check for deletion by "untrusted clients" prior to running prune would be the good approach, which as I understand it, is like #2251.

I'll also watch #1772.

Thank you for taking time answering, I'll close this duplicate & useless issue (which opened later would have been a discussion).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants