Richard Elling <richard.ell...@gmail.com> wrote: > On Feb 20, 2013, at 3:27 PM, Tim Cook <t...@cook.ms> wrote: > > On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling <richard.ell...@gmail.com> > > wrote: > > On Feb 20, 2013, at 2:49 PM, Markus Grundmann <mar...@freebsduser.eu> wrote:
> >> 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
signature.asc
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
