Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Jim Klimov]

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


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

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


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


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Tim Cook]

On Thu, Feb 21, 2013 at 8:34 AM, Jan Owoc  wrote:

> Hi Markus,
>
> On Thu, Feb 21, 2013 at 6:44 AM, Markus Grundmann 
> 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  wrote:
> > # zfs create a/1
> > # zfs create a/1/hold
> > # zfs snapshot a/1/hold@hold
> > # zfs hold 'saveme!' a/1/hold@hold
> > # zfs holds a/1/hold@hold
> > NAME   TAG  TIMESTAMP
> > a/1/hold@hold  saveme!  Wed Feb 20 15:06:29 2013
> > # zfs destroy -r a/1
> > cannot destroy 'a/1/hold@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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Sašo Kiselkov]

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
> ")
> 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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Markus Grundmann]

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 
")
I did'nt need a workaround to protect my filesystems based on snapshots 
with hold-state.


Best regards,
Markus

:-)
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Jan Owoc]

Hi Markus,

On Thu, Feb 21, 2013 at 6:44 AM, Markus Grundmann  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  wrote:
> # zfs create a/1
> # zfs create a/1/hold
> # zfs snapshot a/1/hold@hold
> # zfs hold 'saveme!' a/1/hold@hold
> # zfs holds a/1/hold@hold
> NAME   TAG  TIMESTAMP
> a/1/hold@hold  saveme!  Wed Feb 20 15:06:29 2013
> # zfs destroy -r a/1
> cannot destroy 'a/1/hold@hold': snapshot is busy

Does this do what you want? (zpool destroy is already undo-able)

Jan
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Markus Grundmann]

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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Fabian Keil]

Richard Elling  wrote:

> On Feb 20, 2013, at 3:27 PM, Tim Cook  wrote:
> > On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling  
> > wrote:
> > On Feb 20, 2013, at 2:49 PM, Markus Grundmann  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 " 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] Feature Request for zfs pool/filesystem protection?

[Jim Klimov]

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 " 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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Markus Grundmann]

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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Tim Cook]

On Wed, Feb 20, 2013 at 6:47 PM, Richard Elling wrote:

> On Feb 20, 2013, at 3:27 PM, Tim Cook  wrote:
>
> On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling 
> wrote:
>
>> On Feb 20, 2013, at 2:49 PM, Markus Grundmann 
>> 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 " 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

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Richard Elling]

On Feb 20, 2013, at 3:27 PM, Tim Cook  wrote:
> On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling  
> wrote:
> On Feb 20, 2013, at 2:49 PM, Markus Grundmann  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 " 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.ell...@richardelling.com
+1-760-896-4422









___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Tim Cook]

On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling wrote:

> On Feb 20, 2013, at 2:49 PM, Markus Grundmann 
> 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 " 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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Markus Grundmann]

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" :-)))

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Markus Grundmann]

Am 21.02.2013 00:08, schrieb Mike Gerdts:

On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann  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 " 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@snap
# zfs hold protectme a/b@snap
# zfs destroy a/b
cannot destroy 'a/b': filesystem has children
use '-r' to destroy the following datasets:
a/b@snap
# zfs destroy -r a/b
cannot destroy 'a/b@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@hold
# zfs hold 'saveme!' a/1/hold@hold
# zfs holds a/1/hold@hold
NAME   TAG  TIMESTAMP
a/1/hold@hold  saveme!  Wed Feb 20 15:06:29 2013
# zfs destroy -r a/1
cannot destroy 'a/1/hold@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 " 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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Markus Grundmann]

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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Richard Elling]

On Feb 20, 2013, at 2:49 PM, Markus Grundmann  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 " 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@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

--

richard.ell...@richardelling.com
+1-760-896-4422









___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Mike Gerdts]

On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann  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 " 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@snap
# zfs hold protectme a/b@snap
# zfs destroy a/b
cannot destroy 'a/b': filesystem has children
use '-r' to destroy the following datasets:
a/b@snap
# zfs destroy -r a/b
cannot destroy 'a/b@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@hold
# zfs hold 'saveme!' a/1/hold@hold
# zfs holds a/1/hold@hold
NAME   TAG  TIMESTAMP
a/1/hold@hold  saveme!  Wed Feb 20 15:06:29 2013
# zfs destroy -r a/1
cannot destroy 'a/1/hold@hold': snapshot is busy

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

Mike
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Jan Owoc]

Hi Markus,

On Wed, Feb 20, 2013 at 3:49 PM, Markus Grundmann  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 " 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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?

[Tim Cook]

On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann 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 " 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
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss