This actually works… They successfully back up their files to their account with 0:0 ownership.

But, of course, they are not root on our end so they either lose the ability to write or change the files… Or they lose the ability to read them at all.

The easy solution is this neat rsync argument —fake-super … but I guess you could make this mistake on purpose with permissions that allowed read access to all … and successfully create write once, read, only backups…

Maybe you have made some kind of special dispensation for this, as it would improve the situation for backup purposes, but then it would seem like you got it wrong in a way which I would find super confusing; and, like, are you saying any files owned by users other than root but with other elevated use are fine?

It wasn't people preserving ownership and creating 0:0 files, it was people preserving permissions and sending us chmod 0000 files.

They were root on their end so their broken permissions worked but as soon as they hit their rsync.net filesystem, the 0000 permission meant they could no longer read it.

I think my original idea is still possible: you could do this on purpose (perhaps with 0400 permissions) and create write-once backups on any remote rsync host.

We don't have an app or an interface - it's just, as you say, a filesystem and there aren't any real guardrails. If your source files are 0000 and you 'rsync -a' you will achieve just that.

As for the original thought experiment, a one way chute for information that you can retrieve out of band is kind of interesting ... so Mallory can't gain anything with your credentials because you intentionally mis-wrote your backups but, of course, you could still formally attest your identity and retrieve them from (whatever organization).

Again, just a thought experiment.

I could imagine that being unexpected at times (and if it is, it's yet another argument in favor of --fake-super!)

Could this be made possible using something like user namespaces / containers with their own hostnames?

Containers have been widespread for quite some time now (Docker was first released in 2013, more than a decade ago) and this would seem like a basic bug. I'm willing to believe the kernel was buggy back then, but I would expect it is more robust now.

There's been several. And I wouldn't be surprised if more are still there, or more get introduced.

With a quick keypair generation one can quickly deploy read-only (and probably write-only although I've never tried that) access to select parts of a filesystem and do selective near-line backups of important files into a "history" host of sorts, and even leverage rsync's ability to use hardlinks in place of files that have not changed since the last run so no space is needlessly wasted backing up 400 copies of the same thing.

It was wonderful that I didn't have to write such a wrapper myself.

Unless my script going live long enough i don't use rsync.

My habit has changed since I started using rsync completion:

https://asciinema.org/a/mktcuXSPDTr2Mp1XVbo5tqhK1

Thing is you just need to write what you want rsync to do in English and it will generate all the appropriate flags for rsync.

If done correctly, it could allow you to perform restic backups and restores without granting the ability to delete backups.

I am guessing one would want to disable the Sftp subsystem for SSH too.