Hacker News Reader

Comment by rsync | Hacker News Reader

There is a mistake that some people make when pointing simple rsync jobs to us - they preserve ownership but send files owned by root.

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…

View on HN

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?

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.

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

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.

Now that you mention preserving ownership: Does rsync preserve setuid and setgid by default?

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

> But, of course, they are not root on our end

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

Linux sometimes has "trouble" (security bugs) distinguishing real root and container root, so I wouldn't suggest it.

Can I read more about this? Wouldn't these security bugs quickly fixed?

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.

https://duckduckgo.com/?t=ffab&q=Linux+user+namespace+vulner...

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

Reply on news.ycombinator.com