4 ms·
I'm talking about a ZFS stream that has been deliberately corrupted and then sent to you to be received as a filesystem -- when it will in fact cause ZFS to pan
by bcantrill 11y ago
I'm talking about a ZFS stream that has been deliberately corrupted and then sent to you to be received as a filesystem -- when it will in fact cause ZFS to panic (or worse). So I mean "byzantine" in the "characterized by deviousness" sense: someone actively trying to do harm to you. Or perhaps I have misunderstood the functionality that you offer?
- rsync 11y agoOk, that is not what I was thinking of. We have made no specific provisions for this. However, we were scared enough about "unknown unknowns" that we set up this aspect of our service such that every ZFS send/recv customer gets their own zpool inside their own bhyve. So it might be a DOS attack, but I don't think there is a data attack against rsync.net here. Comments ? Unrelated: I'm curious - when I speak of snapshots corrupted by extended attributes or "disappearing snapshots", do you know what I mean ? Maybe we should talk :)
- bcantrill 11y agoI don't know enough about bhyve or your implementation to be able to comment, but if you assume that any system that has ever received a ZFS stream from a user is entirely compromised, then perhaps you can work around it that way. I'm not aware of a disappearing snapshot problem; has there been something sent to the ZFS list about this? Would have been a good topic of discussion for the OpenZFS Developers Summit a few weeks ago... ;)
- rsync 11y agoYes, that's exactly the model - these users have their own zpool inside their own VM.