zfs discuss - Feb 2013 - Feature Request for zfs pool/filesystem protection?

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).

It''s anywhere here on this list their can discuss/forward this feature 
request? I hope you have
understand my post ;-)

Thanks and best regards,
Markus

On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann <markus at
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<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).
>
> It''s anywhere here on this list their can discuss/forward this
feature
> request? I hope you have
> understand my post ;-)
>
> Thanks and best regards,
> Markus
>
>
>
I think you''re underestimating your English, it''s quite good
:)  In any
case, I think the proposal is a good one.  With the default behavior being
off, it won''t break anything for existing datasets, and it can
absolutely
help prevent a fat finger or a lack of caffeine ruining someone''s day.

If the feature is already there somewhere, I''m sure someone will chime
in.

--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20130220/d7b09435/attachment.html>

Hi Markus,

On Wed, Feb 20, 2013 at 3:49 PM, Markus Grundmann <markus at
freebsduser.eu> wrote:
> 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
Zfs already allows for custom properties. You could create your own
property, like "protected", and set it to anything you wanted to.
> 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).
"zpool destroy tank" can be undone as long as you didn''t
overwrite the
partitions with something (the data is still there). The more
dangerous one is "zfs destroy". I suggest putting in a snapshot, which
counts as a child filesystem, so you would have to do "zfs destroy -r
tank/filesystem" to recursively destroy all the children.

I would imagine you could write some sort of wrapper for the "zfs"
command that checks if the command includes "destroy" and then check
for the existence of your custom property.

Jan

On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann <markus at
freebsduser.eu> wrote:
> 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).
>
> It''s anywhere here on this list their can discuss/forward this
feature
> request? I hope you have
> understand my post ;-)
I like the idea and it is likely not very hard to implement.  This is
very similar to how snapshot holds work.

# zpool upgrade -v | grep -i hold
 18  Snapshot user holds

So long as you aren''t using a really ancient zpool version, you could
use this feature to protect your file systems.

# zfs create a/b
# zfs snapshot a/b at snap
# zfs hold protectme a/b at snap
# zfs destroy a/b
cannot destroy ''a/b'': filesystem has children
use ''-r'' to destroy the following datasets:
a/b at snap
# zfs destroy -r a/b
cannot destroy ''a/b at snap'': snapshot is busy

Of course, snapshots aren''t free if you write to the file system.  A
way around that is to create an empty file system within the one that
you are trying to protect.

# zfs create a/1
# zfs create a/1/hold
# zfs snapshot a/1/hold at hold
# zfs hold ''saveme!'' a/1/hold at hold
# zfs holds a/1/hold at hold
NAME           TAG      TIMESTAMP
a/1/hold at hold  saveme!  Wed Feb 20 15:06:29 2013
# zfs destroy -r a/1
cannot destroy ''a/1/hold at hold'': snapshot is busy

Extending the hold mechanism to filesystems and volumes would be quite nice.

Mike

On Feb 20, 2013, at 2:49 PM, Markus Grundmann <markus at 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
> 
> It''s anywhere here on this list their can discuss/forward this
feature request? I hope you have
> understand my post ;-)
> 
> Thanks and best regards,
> Markus
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--

Richard.Elling at RichardElling.com
+1-760-896-4422









-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20130220/0a7442b6/attachment.html>

Am 21.02.2013 00:02, schrieb Tim Cook:
> I think you''re underestimating your English, it''s quite
good :)
Thank you Tim :-)
> In any case, I think the proposal is a good one.  With the default 
> behavior being off, it won''t break anything for existing datasets,
and
> it can absolutely help prevent a fat finger or a lack of caffeine 
> ruining someone''s day.
>
> If the feature is already there somewhere, I''m sure someone will
chime
> in.
>
> --Tim
Yes! After some minutes I have found places in the source to patch it 
but is a long way to go them *g*
The better way is when this property was available for all operating 
systems and not only in my sand box.

Regards,
Markus

Am 21.02.2013 00:08, schrieb Mike Gerdts:
> On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann <markus at
freebsduser.eu> wrote:
>> 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).
>>
>> It''s anywhere here on this list their can discuss/forward this
feature
>> request? I hope you have
>> understand my post ;-)
> I like the idea and it is likely not very hard to implement.  This is
> very similar to how snapshot holds work.
>
> # zpool upgrade -v | grep -i hold
>   18  Snapshot user holds
>
> So long as you aren''t using a really ancient zpool version, you
could
> use this feature to protect your file systems.
>
> # zfs create a/b
> # zfs snapshot a/b at snap
> # zfs hold protectme a/b at snap
> # zfs destroy a/b
> cannot destroy ''a/b'': filesystem has children
> use ''-r'' to destroy the following datasets:
> a/b at snap
> # zfs destroy -r a/b
> cannot destroy ''a/b at snap'': snapshot is busy
>
> Of course, snapshots aren''t free if you write to the file system. 
A
> way around that is to create an empty file system within the one that
> you are trying to protect.
>
> # zfs create a/1
> # zfs create a/1/hold
> # zfs snapshot a/1/hold at hold
> # zfs hold ''saveme!'' a/1/hold at hold
> # zfs holds a/1/hold at hold
> NAME           TAG      TIMESTAMP
> a/1/hold at hold  saveme!  Wed Feb 20 15:06:29 2013
> # zfs destroy -r a/1
> cannot destroy ''a/1/hold at hold'': snapshot is busy
>
> Extending the hold mechanism to filesystems and volumes would be quite
nice.
>
> Mike
Hi Mike! Yes that I have understand. zfs filesystems can protect on this 
way. With a new "protected" property the pool and the vdev''s
are lay
under an additional security layer. We are all humans (that''s good) but
we are full with errors *lol*

The protection property helps to lock modification on the infrastructure 
of zfs. The pools. With a simple "zpool set protected=off
<pool>" all
modifications are available. The different is you must type as 
administrator additional command to unlock the pool for your next 
action. An example: In many linux distributions you will be ask
"Sure?"
when you type "rm *". That''s fine or? zpool and zfs commands
working
without any warnings. Yes I was "root" but root is not god ;-)

-Markus

>
> 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
>
>
Hi Richard!

I think it''s implemented but I have never used.
I hope this feature can "protect zfs before markus aka root" :-)))

On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling <richard.elling at
gmail.com>wrote:
> On Feb 20, 2013, at 2:49 PM, Markus Grundmann <markus at
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.


--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20130220/ce82ce62/attachment.html>

On Feb 20, 2013, at 3:27 PM, Tim Cook <tim at cook.ms>
wrote:
> On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling <richard.elling at
gmail.com> wrote:
> On Feb 20, 2013, at 2:49 PM, Markus Grundmann <markus at
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

--

Richard.Elling at RichardElling.com
+1-760-896-4422









-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20130220/f51a4759/attachment-0001.html>

On Wed, Feb 20, 2013 at 6:47 PM, Richard Elling <richard.elling at
gmail.com>wrote:
> On Feb 20, 2013, at 3:27 PM, Tim Cook <tim at cook.ms> wrote:
>
> On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling <richard.elling at
gmail.com>wrote:
>
>> On Feb 20, 2013, at 2:49 PM, Markus Grundmann <markus at
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20130220/b8c50f4c/attachment.html>

On 02/21/2013 02:59 AM, Tim Cook wrote:
>
> 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
ACK. That''s what I mean ...

On 2013-02-20 23:49, Markus Grundmann wrote:
> 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).

Hello all,

   I don''t want to really hijack this thread, but this request seems
like a nice complement to one I voiced a few times and recently posted
into the bugtracker lest it be forgotten:

Feature #3568: Add a ZFS dataset attribute to disallow creation of
snapshots, ever: https://www.illumos.org/issues/3568

   It is somewhat of an opposite desire - to not allow creation of
datasets (snapshots) rather than forbid their destruction as requested
here, but to a similar effect: to not let some scripted or thoughtless
manual jobs abuse the storage by wasting space in some datasets in the
form of snapshot creation.

//Jim

Richard Elling <richard.elling at gmail.com> wrote:
> On Feb 20, 2013, at 3:27 PM, Tim Cook <tim at cook.ms> wrote:
> > On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling <richard.elling at
gmail.com> wrote:
> > On Feb 20, 2013, at 2:49 PM, Markus Grundmann <markus at
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20130221/82f9a509/attachment.bin>

Moin Fabian :-)

I think the "zfs allow|deny" feature is only for filesystems. I wish
me
a feature to protect the complete pool. The property is restricted to 
zpool commands.

On my notebook I have created a pool with simulated drives 
(gpt/drive1..n) and without any warnings or "you are sure (y/n)" I can
destroy them after one second.

Sorry but that''s not OK for me and I will not write any wrapper scripts
to protect my system. I think a new property named "protected=on|off" 
for pool and/or filesystems is a good enhancement for this great 
filesystem. I love zfs.

For my personal reasons I will try to rewrite some pieces of the current 
source code in FreeBSD to get the wanted functionality for me.
Please wish me good luck *g*

Gruss
Markus

Hi Markus,

On Thu, Feb 21, 2013 at 6:44 AM, Markus Grundmann <markus at
freebsduser.eu> wrote:
> I think the "zfs allow|deny" feature is only for filesystems. I
wish me a
> feature to protect the complete pool. The property is restricted to zpool
> commands.
>
> On my notebook I have created a pool with simulated drives (gpt/drive1..n)
> and without any warnings or "you are sure (y/n)" I can destroy
them after
> one second.
>
[SNIP]
>
> For my personal reasons I will try to rewrite some pieces of the current
> source code in FreeBSD to get the wanted functionality for me.
> Please wish me good luck *g*
I think Mike''s solution is exactly what you are looking for. You can
make a snapshot, hold it, and then zfs destroy (and even zfs destroy
-r) will fail. The only thing you can do is run the command(s) to
"un-hold" the snapshot.

On Wed, Feb 20, 2013 at 4:08 PM, Mike Gerdts <mgerdts at gmail.com>
wrote:
> # zfs create a/1
> # zfs create a/1/hold
> # zfs snapshot a/1/hold at hold
> # zfs hold ''saveme!'' a/1/hold at hold
> # zfs holds a/1/hold at hold
> NAME           TAG      TIMESTAMP
> a/1/hold at hold  saveme!  Wed Feb 20 15:06:29 2013
> # zfs destroy -r a/1
> cannot destroy ''a/1/hold at hold'': snapshot is busy
Does this do what you want? (zpool destroy is already undo-able)

Jan

On 02/21/2013 03:34 PM, Jan Owoc wrote:
> Does this do what you want? (zpool destroy is already undo-able) Jan 
Jan that''s not was I want.
I want set a property that''s enable/disable all modifications with
zpool
commands (e.g. "zfs destroy", "zfs detach" ...)

This property is also possible for zfs commands (e.g. "zfs destroy 
<filesystem>")
I did''nt need a workaround to protect my filesystems based on snapshots
with hold-state.

Best regards,
Markus

:-)

On 02/21/2013 04:02 PM, Markus Grundmann wrote:
> On 02/21/2013 03:34 PM, Jan Owoc wrote:
>> Does this do what you want? (zpool destroy is already undo-able) Jan 
> 
> Jan that''s not was I want.
> I want set a property that''s enable/disable all modifications with
zpool
> commands (e.g. "zfs destroy", "zfs detach" ...)
> 
> This property is also possible for zfs commands (e.g. "zfs destroy
> <filesystem>")
> I did''nt need a workaround to protect my filesystems based on
snapshots
> with hold-state.
You''ve already been told how to do it - create a custom property and
alias your zfs/zpool commands to a shell script which checks them.

Cheers,
--
Saso

On Thu, Feb 21, 2013 at 8:34 AM, Jan Owoc <jsowoc at gmail.com> wrote:
> Hi Markus,
>
> On Thu, Feb 21, 2013 at 6:44 AM, Markus Grundmann <markus at
freebsduser.eu>
> wrote:
> > I think the "zfs allow|deny" feature is only for
filesystems. I wish me a
> > feature to protect the complete pool. The property is restricted to
zpool
> > commands.
> >
> > On my notebook I have created a pool with simulated drives
> (gpt/drive1..n)
> > and without any warnings or "you are sure (y/n)" I can
destroy them after
> > one second.
> >
> [SNIP]
> >
> > For my personal reasons I will try to rewrite some pieces of the
current
> > source code in FreeBSD to get the wanted functionality for me.
> > Please wish me good luck *g*
>
> I think Mike''s solution is exactly what you are looking for. You
can
> make a snapshot, hold it, and then zfs destroy (and even zfs destroy
> -r) will fail. The only thing you can do is run the command(s) to
> "un-hold" the snapshot.
>
> On Wed, Feb 20, 2013 at 4:08 PM, Mike Gerdts <mgerdts at gmail.com>
wrote:
> > # zfs create a/1
> > # zfs create a/1/hold
> > # zfs snapshot a/1/hold at hold
> > # zfs hold ''saveme!'' a/1/hold at hold
> > # zfs holds a/1/hold at hold
> > NAME           TAG      TIMESTAMP
> > a/1/hold at hold  saveme!  Wed Feb 20 15:06:29 2013
> > # zfs destroy -r a/1
> > cannot destroy ''a/1/hold at hold'': snapshot is busy
>
> Does this do what you want? (zpool destroy is already undo-able)
>
> Jan
>
>
That suggestion makes the very bold assumption that you want a
long-standing snapshot of the dataset.  If it''s a rapidly changing
dataset,
the snapshot will become an issue very quickly.

--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20130221/8f82e1f5/attachment.html>

It''s anyone here on the list that''s have some tips for me what
files are
to modify ? :-)

In my current source tree now is a new property "PROTECTED" available 
both for pool- und "zfs"-objects. I have also two functions added to 
"get" and "set" the property above. The source code tree is
very big and
some files have the same name in different locations. GREP seems to be 
my new friend.

The source code is very nice and good to understand. I will report my 
results to you (year 2014, 2015 ..., I don''t know *lol* )

-Markus
> That suggestion makes the very bold assumption that you want a 
> long-standing snapshot of the dataset.  If it''s a rapidly changing
> dataset, the snapshot will become an issue very quickly.
>
> --Tim

On 2013-02-21 16:54, Markus Grundmann wrote:
> It''s anyone here on the list that''s have some tips for me
what files are
> to modify ? :-)
>
> In my current source tree now is a new property "PROTECTED"
available
> both for pool- und "zfs"-objects. I have also two functions added
to
> "get" and "set" the property above. The source code
tree is very big and
> some files have the same name in different locations. GREP seems to be
> my new friend.
You might also benefit from on-line "grepping" here:

http://src.illumos.org/source/search?q=zfs_do_hold&defs=&refs=&path=&hist=&project=freebsd-head

There is a project "freebsd-head" in illumos codebase; I have no idea
how actual it is for the BSD users.

HTH,
//Jim