Hacker News Reader

Comment by zargon | Hacker News Reader

Isn't this "no-delete permission" just a made-up mode for testing the borg storage layer while simulating a lack of permissions for deleting and overwriting? In actual deployment, whatever backing store is used must have the access control primitives to implement such a restriction. I don't know how to do this on a posix filesystem, for example. Gemini gave me a convoluted solution that requires the client to change permissions after creating the files.

View on HN

at first it was implemented to easily test permission restricted storages (can't easily test on all sorts of cloud storages).

it was implemented for "file:" (which is also used for "ssh://" repos) and there are automated tests for how borg behaves on such restricted permissions repos.

after the last beta I also added cli flags to "borg serve", so it now also can be used via .ssh/authorized_keys more easily.

so it can now also be used for practical applications, not just for testing.

not for production yet though, borg2 is still in beta.

help with testing is very welcome though!

Currently, you can either provide the `BORG_REPO_PERMISSIONS` env var to borg [0] or `--permissions` flag to `borg serve` [1]. You can then enforce this as part of your `authorized_keys` command, for example.

[0] https://github.com/borgbackup/borg/blob/3cf8d7cf2f36246ded75...

[1] https://github.com/borgbackup/borg/blob/3cf8d7cf2f36246ded75...

Ah, I was searching borgstore for no-delete, but it gets exploded into itemized permissions in borg. Documentation seems to be non-existent, as the only mention seems to be the changelog where it suggests this only exists for testing. But I suppose it's not released yet.

Reply on news.ycombinator.com