3 ms·

I am extremely confused by this, as this seems like at least a bug if not a security issue. If I am not running as root on your server, how am I getting files o

by saurik 2y ago

I am extremely confused by this, as this seems like at least a bug if not a security issue. If I am not running as root on your server, how am I getting files owned by root at all? A normal user can't just hand files to root, for a number of good reasons. As far as I remember, the behavior of rsync -a if the other side is not running as root is that it just doesn't save the ownership (as opposed to error; "work but the files are owned by root and can no longer be read" is not an option). 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?

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.

by saurik 2y ago

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.