>>>>> "tf" == Tim Foster <[EMAIL PROTECTED]> writes:

    tf> store flat zfs send-streams

I thought it was said over and over that 'zfs send' streams could
never be stored, only piped to 'zfs recv'.  If you store one and then
find it's corrupt, the answer is ``didn't let ZFS handle redundancy,''
``sysadmin's fault, not a bug,'' ``it was corrupted by weak TCP
checksums, USB gremlins, poor FLASH ECC, traces on your motherboard
without parity (it does happen!  be glad it didn't happen silently!
restore the pool from ba---oh, that was your backup.  shit.)''

Also I don't think it is currently safe to allow mounting of
stick-based USB ZFS filesystems on a multi-user machine because
someone coudl show up at a SunRay cluster with one of these
poison-sticks that panics on import.  I stumbled onto a bugnumber with
a wild idea for addressing this:

 http://bugs.opensolaris.org/view_bug.do?bug_id=4879357

The suggestion is scary that problems with one pool will restart ZFS
for all pools, and it seems like something that could loop.  but the
idea of a single bulletted-whitepaper-feechur addressing a whole class
of problems is pretty attractive.  

I guess using FUSE for all removable media is another path, but feels
like defeat---the hotplug stuff isn't always perfect on Macs but at
least they don't seem to panic from corrupt filesystems often, and
they do proper high-speed in-kernel filesystems.  I guess I'm asking
for something more drastic and beyond common-practice with the SunRay
reference though---to treat USB sticks as untrusted input analagous to
network packets, meaning if you can create a stick that makes the
kernel panic, you've potentially discovered a kernel-level
privilege-escalation exploit, not just a broken stick.  With this
whole power-saving theme of ``containers'' and so on, it's no longer
reasonable to punt and say, ``well he had physical access to the
machine anyway---he could have taken the cover off and done
whatever,'' because we'd like to allow people to introduce USB sticks
over the network.

Attachment: pgpu7hfJELTwA.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to