4 ms·

Forgive me ... my lead engineer has rebuked me for mis-remembering this ... It wasn't people preserving ownership and creating 0:0 files, it was people preserv

by rsync 2y ago

Forgive me ... my lead engineer has rebuked me for mis-remembering this ... 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.

xk3 2y ago
hmm this still seems like a bug to me. File ownership and file permissions are a filesystem construct. Whether you use chmod 777 or 755 doesn't change a file's md5sum, for example. It's up to your service to not apply file permissions that don't make sense. If backups are write-only with no mechanism for reading they may as well be to /dev/null
- rsync 2y ago
  No, not a bug. 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.