Discussion:
Feature Request for zfs pool/filesystem protection?
(too old to reply)
Markus Grundmann
2013-02-20 22:49:29 UTC
Permalink
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
Tim Cook
2013-02-20 23:02:24 UTC
Permalink
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
Markus Grundmann
2013-02-20 23:12:23 UTC
Permalink
Post by Tim Cook
I think you're underestimating your English, it's quite good :)
Thank you Tim :-)
Post by Tim Cook
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
Jan Owoc
2013-02-20 23:02:27 UTC
Permalink
Hi Markus,
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
Mike Gerdts
2013-02-20 23:08:53 UTC
Permalink
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/***@snap
# zfs hold protectme a/***@snap
# zfs destroy a/b
cannot destroy 'a/b': filesystem has children
use '-r' to destroy the following datasets:
a/***@snap
# zfs destroy -r a/b
cannot destroy 'a/***@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
# zfs hold 'saveme!' a/1/***@hold
# zfs holds a/1/***@hold
NAME TAG TIMESTAMP
a/1/***@hold saveme! Wed Feb 20 15:06:29 2013
# zfs destroy -r a/1
cannot destroy 'a/1/***@hold': snapshot is busy

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

Mike
Markus Grundmann
2013-02-20 23:21:41 UTC
Permalink
Post by Mike Gerdts
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 destroy a/b
cannot destroy 'a/b': filesystem has children
# zfs destroy -r a/b
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
NAME TAG TIMESTAMP
# zfs destroy -r a/1
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
Richard Elling
2013-02-20 23:09:21 UTC
Permalink
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
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--

***@RichardElling.com
+1-760-896-4422
Markus Grundmann
2013-02-20 23:25:44 UTC
Permalink
Post by Richard Elling
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" :-)))
Tim Cook
2013-02-20 23:27:58 UTC
Permalink
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
Richard Elling
2013-02-21 00:47:11 UTC
Permalink
Post by Richard Elling
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

--

***@RichardElling.com
+1-760-896-4422
Tim Cook
2013-02-21 01:59:38 UTC
Permalink
Post by Tim Cook
Post by Markus Grundmann
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
Markus Grundmann
2013-02-21 07:44:45 UTC
Permalink
Post by Tim Cook
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 ...
Fabian Keil
2013-02-21 12:55:59 UTC
Permalink
Post by Richard Elling
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 ...
Post by Richard Elling
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.
Post by Richard Elling
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
Markus Grundmann
2013-02-21 13:44:36 UTC
Permalink
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
Jan Owoc
2013-02-21 14:34:54 UTC
Permalink
Hi Markus,
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.
# zfs create a/1
# zfs create a/1/hold
NAME TAG TIMESTAMP
# zfs destroy -r a/1
Does this do what you want? (zpool destroy is already undo-able)

Jan
Markus Grundmann
2013-02-21 15:02:53 UTC
Permalink
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

:-)
Sašo Kiselkov
2013-02-21 15:16:06 UTC
Permalink
Post by Markus Grundmann
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
Tim Cook
2013-02-21 15:36:45 UTC
Permalink
Post by Jan Owoc
Hi Markus,
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.
# zfs create a/1
# zfs create a/1/hold
NAME TAG TIMESTAMP
# zfs destroy -r a/1
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
Markus Grundmann
2013-02-21 15:54:33 UTC
Permalink
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
Post by Tim Cook
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
Jim Klimov
2013-02-21 19:02:09 UTC
Permalink
Post by Markus Grundmann
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

Jim Klimov
2013-02-21 10:40:37 UTC
Permalink
Post by Markus Grundmann
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
Loading...