Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?
Richard Elling richard.ell...@gmail.com wrote: On Feb 20, 2013, at 3:27 PM, Tim Cook t...@cook.ms wrote: On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling richard.ell...@gmail.com wrote: On Feb 20, 2013, at 2:49 PM, Markus Grundmann mar...@freebsduser.eu wrote: My name is Markus and I living in germany. I'm new to this list and I have a simple question related to zfs. My favorite operating system is FreeBSD and I'm very happy to use zfs on them. It's possible to enhance the properties in the current source tree with an entry like protected? I find it seems not to be difficult but I'm not an professional C programmer. For more information please take a little bit of time and read my short post at http://forums.freebsd.org/showthread.php?t=37895 Inaccessible for me without extra steps to circumvent the aggressive IP blacklisting ... I have reviewed some pieces of the source code in FreeBSD 9.1 to find out how difficult it was to add an pool / filesystem property as an additional security layer for administrators. Whenever I modify zfs pools or filesystems it's possible to destroy [on a bad day :-)] my data. A new property protected=on|off in the pool and/or filesystem can help the administrator for datalost (e.g. zpool destroy tank or zfs destroy tank/filesystem command will be rejected when protected=on property is set). Look at the delegable properties (zfs allow). For example, you can delegate a user to have specific privileges and then not allow them to destroy. Note: I'm only 99% sure this is implemented in FreeBSD, hopefully someone can verify. It's implemented and works for me. With the version of allow I'm looking at, unless I'm missing a setting, it looks like it'd be a complete nightmare. I see no concept of deny, so that means you either have to give *everyone* all permissions besides delete, or you have to go through every user/group on the box and give specific permissions and on top of not allowing destroy. And then if you change your mind later you have to go back through and give everyone you want to have that feature access to it. That seems like a complete PITA to me. On most systems I use most users don't need any delegations. I agree that manually changing already existing delegations currently is a bit inconvenient, but you usually don't have to do it every day and you can use a script to increase the convenience. As far as protected=on or Jim's #3568 are concerned I think a more powerful mechanism would be negative delegations that override the standard delegations and can also restrict root, or an option that turns the standard delegation into a white-list that applies to everyone including root. For extra protection/inconvenience it could be immutable if the securelevel is above 1. I don't remember ever accidentally destroying a pool or file system, but occasionally failed at automatically destroying all but the last X snapshots using a ad-hoc shell command and don't think a protect option would have helped there. I now use a script for this: http://www.fabiankeil.de/sourcecode/zfs-snapshot-destroyer/zsd.pl On datasets where I rarely destroy snapshots I don't grant me destroy privileges which means I have to use sudo which should further reduce the risk of accidents. Fabian signature.asc Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] dm-crypt + ZFS on Linux
John Baxter johnleebax...@gmail.com wrote: After searching for dm-crypt and ZFS on Linux and finding too little information, I shall ask here. Please keep in mind this in the context of running this in a production environment. We have the need to encypt our data, approximately 30TB on three ZFS volumes under Solaris 10. The volumes currently reside on iscsi sans connected via 10Gb/s ethernet. We have tested Solaris 11 with ZFS encrypted volumes and found the performance to be very poor and have an open bug report with Oracle. Was the performance acceptable without encryption? We are a Linux shop and since performance is so poor and still no resolution, we are considering ZFS on Linux with dm-crypt. I have read once or twice that if we implemented ZFS + dm-crypt we would loose features, however which features are not specified. We currently mirror the volumes across identical iscsi sans with ZFS and we use hourly ZFS snapshots to update our DR site. Which features of ZFS are lost if we use dm-crypt? My guess would be they are related to raidz but unsure. It depends on where you put the encryption layer. If you put it below ZFS, no ZFS feature has to be lost although bugs in the encryption layer may make the whole setup less reliable. Of course that's true for Oracle's ZFS encryption as well. If you put the encryption layer on top of ZFS, features like compression and deduplication should be ineffective. It will not encrypt the ZFS metadata, but it allows you to keep parts of the data on the pool intentionally (or unintentionally) unencrypted. If your application doesn't work with raw devices, you need a file system on top of the encryption layer again. I'm not aware of anything raidz-related that is lost in either setup. I haven't used ZFS with dm-crypt on GNU/Linux, but if I had to, I'd put dm-crypt below ZFS and would rather split the pool than put dm-crypt on top of ZFS. My impression is that ext4 on dm-crypt on ZFS is a popular setup (among bloggers), but I have no idea why and certainly wouldn't want to use it in a production environment. Just in case your GNU/Linux experiments don't work out, you could also try ZFS on Geli on FreeBSD which works reasonably well. Fabian signature.asc Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Solaris derivate with the best long-term future
Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Wed, 11 Jul 2012, Eugen Leitl wrote: It would be interesting to see when zpool versions 28 will be available in the open forks. Particularly encryption is a very useful functionality. Illumos advanced to zpool version 5000 and this is available in the latest OpenIndiana development release. Does that make you happy? As far as which Solaris derivate has the best future, it is clear that Illumos has a lot of development energy right now and there is little reason to believe that this energy will cease. Illumos-derived distributions may come and go but it looks like Illumos has a future, particularly once it frees itself from all Sun-derived binary components. FreeBSD 10.0-CURRENT is at zpool version 5000 as well. It supports ZFS-independent full disk encryption through geli and gbde. I've been using ZFS on geli since the ZFS import in 2007 and while there are still a couple of unresolved bugs, overall I'm quite satisfied. Of course FDE is less flexible than the per-dataset encryption offered by Oracle ZFS, but personally I prefer to encrypt all the data in the pool anyway and Oracle ZFS is not designed to do that: https://blogs.oracle.com/darren/entry/zfs_encryption_what_is_on I certainly wouldn't mind additionally being able to use encryption inside ZFS, though. Fabian signature.asc Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
