this post was submitted on 19 Jun 2026
56 points (95.2% liked)

Selfhosted

60320 readers
563 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

Let's say you have access to a remote machine and use it to copy backups occasionally, eg with rsync. Your local machine has credentials stored that allow write access on the remote machine, however if the local account was compromised that could also allow access to the remote machine and the data stored there.

How can you grant access to an account to write remotely, but also protect the data from this account? One possibility could be to change the permissions on the data after it is copied to prevent deletion/interference, although I'm just making this up. Is there a standard practise for this?

you are viewing a single comment's thread
view the rest of the comments
[–] HelloRoot@lemy.lol 1 points 1 week ago* (last edited 1 week ago)

OP asked:

How can you grant access to an account to write remotely, but also protect the data from this account?

So I was thinking that the account should not be able to delete the filesystem in an unrecoverable way. Like overriding the current fs with random data or an encrypted fs and filling it etc.

Like I said on a Hetzner storage box, multiple users get access to the same system, but each one only has file editing commands, not fs editing and they can only access their assigned directory. So if the system does scheduled snapshots (outside of that user's scope of access) there is no way for a user to delete the files beyond recoverability. (no matter if their own files or other users files).

The user can still delete their own data. But because the fs is cow with snapshots (like btrfs) and they can not touch that, the data can be recovered easily.