On Wed, Feb 20, 2013 at 6:47 PM, 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: >> >> Hi! >> >> 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 >> >> 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. >> -- richard >> >> > > 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. > > > :-) they don't call it "idiot-proofing" for nothing! :-) > > But seriously, one of the first great zfs-discuss wars was over the > request for a > "-f" flag for "destroy." The result of the research showed that if you > typed "destroy" > then you meant it, and adding a "-f" flag just teaches you to type > "destroy -f" instead. > See also "kill -9" > -- richard > > I hear you, but in his scenario of using scripts for management, there isn't necessarily human interaction to confirm the operation (appropriately or not). Having a pool property seems like an easy way to prevent a mis-parsed or outright incorrect script from causing havoc on the system. --Tim
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
