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

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


Attachment: signature.asc
Description: PGP signature

zfs-discuss mailing list

Reply via email to