Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?
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 ___ 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 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
Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?
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?
Hi Markus, On Thu, Feb 21, 2013 at 6:44 AM, Markus Grundmann mar...@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 mger...@gmail.com 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?
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 :-) ___ 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?
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 ___ 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?
On Thu, Feb 21, 2013 at 8:34 AM, Jan Owoc jso...@gmail.com wrote: Hi Markus, On Thu, Feb 21, 2013 at 6:44 AM, Markus Grundmann mar...@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 mger...@gmail.com 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?
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?
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_holddefs=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?
On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann mar...@freebsduser.euwrote: 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=37895http://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 ___ 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?
Hi Markus, On Wed, Feb 20, 2013 at 3:49 PM, Markus Grundmann mar...@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 ___ 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?
On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann mar...@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@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?
On Feb 20, 2013, at 2:49 PM, Markus Grundmann mar...@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@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?
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?
Am 21.02.2013 00:08, schrieb Mike Gerdts: On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann mar...@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@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 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 ___ 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?
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?
On Wed, Feb 20, 2013 at 5:09 PM, Richard Elling richard.ell...@gmail.comwrote: On Feb 20, 2013, at 2:49 PM, Markus Grundmann mar...@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 ___ 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?
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: 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.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?
On Wed, Feb 20, 2013 at 6:47 PM, Richard Elling richard.ell...@gmail.comwrote: 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.comwrote: On Feb 20, 2013, at 2:49 PM, Markus Grundmann mar...@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 ___ 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?
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
