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

Reply via email to